一句話總結(jié)：
HTTP以明文方式發(fā)送內(nèi)容蔗崎，不驗(yàn)證服務(wù)器身份酵幕，不提供數(shù)據(jù)加密
HTTPS在HTTP基礎(chǔ)上加了SSL協(xié)議，驗(yàn)證服務(wù)器身份缓苛，加密傳輸?shù)臄?shù)據(jù)
下面具體總結(jié)一下HTTPS如何實(shí)現(xiàn)身份驗(yàn)證+數(shù)據(jù)加密的：
數(shù)據(jù)加密：
- 客戶端和服務(wù)器之間的數(shù)據(jù)加密是對(duì)稱的（這是為了提高效率芳撒，數(shù)據(jù)很多的情況下，非對(duì)稱加密效率低）未桥，實(shí)現(xiàn)對(duì)稱加密笔刹，只需要一把鑰匙（簡(jiǎn)稱密鑰），密鑰只有客戶端和服務(wù)器知道冬耿，其他人不知道舌菜。
- 這把密鑰的是由客戶端生成的，生成過程采用非對(duì)稱加密亦镶，具體過程如下
- 客戶端向服務(wù)器要服務(wù)器的公鑰日月，用來加密對(duì)稱加密的密鑰
- 服務(wù)器發(fā)給客戶端服務(wù)器的公鑰，客戶端收到后缤骨，首先生成一個(gè)隨機(jī)數(shù)爱咬，這個(gè)隨機(jī)數(shù)就是密鑰，然后用這把服務(wù)器的公鑰加密密鑰
- 客戶端把加密的密鑰發(fā)給服務(wù)器
- 服務(wù)器用自己的私鑰解密绊起，得到了對(duì)稱加密的密鑰（因?yàn)橹挥蟹?wù)器的私鑰能解服務(wù)器的公鑰精拟，所以得到的密鑰只有客戶端和服務(wù)器知道，其他人不知道）
這就是數(shù)據(jù)加密的過程：非對(duì)稱加密生成密鑰虱歪，用密鑰進(jìn)行數(shù)據(jù)的對(duì)稱加密蜂绎。
然而這里有個(gè)問題，服務(wù)器可能會(huì)被冒充笋鄙，假服務(wù)器在中間發(fā)送假的公鑰荡碾，客戶端以為自己在和服務(wù)器對(duì)稱加密通信，實(shí)際是和假的服務(wù)器對(duì)稱加密通信局装。
解決辦法就是服務(wù)器身份驗(yàn)證坛吁，具體如下：
- 為了驗(yàn)證服務(wù)器的身份（或者說是安全傳輸服務(wù)器的公鑰）劳殖，解決方法是申請(qǐng)一個(gè)服務(wù)器的數(shù)字證書
- 數(shù)字證書是服務(wù)器去權(quán)威機(jī)構(gòu)（CA）申請(qǐng)的，包含的是用權(quán)威機(jī)構(gòu)的私鑰加密的兩個(gè)信息：服務(wù)器的公鑰拨脉，數(shù)字簽名（對(duì)證書內(nèi)容用Hash函數(shù)哆姻，生成證書摘要，再用權(quán)威機(jī)構(gòu)的私鑰加密）玫膀。這個(gè)數(shù)字證書只有權(quán)威機(jī)構(gòu)的公鑰才能解開
- 這樣服務(wù)器不直接給客戶端發(fā)服務(wù)器的公鑰矛缨，而是發(fā)服務(wù)器的數(shù)字證書
- 客戶端收到服務(wù)器的數(shù)字證書，就用權(quán)威機(jī)構(gòu)的公鑰（正規(guī)的瀏覽器提供）解開帖旨，得到服務(wù)器的公鑰和數(shù)字簽名箕昭。（這里能用權(quán)威機(jī)構(gòu)的公鑰解密，說明這個(gè)證書的確來自權(quán)威機(jī)構(gòu)）
- 客戶端用權(quán)威機(jī)構(gòu)的私鑰解開數(shù)字簽名解阅，得到證書摘要H1落竹，再用Hash函數(shù)自己生成一次證書摘要H2，如果H1等于H2货抄，說明數(shù)字證書沒有被篡改過（如果數(shù)字證書被篡改了述召，篡改者必須對(duì)應(yīng)的修改數(shù)字簽名，但篡改者沒有權(quán)威機(jī)構(gòu)的私鑰蟹地，無法生成對(duì)應(yīng)的數(shù)字簽名积暖，導(dǎo)致H1不等于H2）
- 證書沒有被篡改的基礎(chǔ)上，客戶端檢查證書上的使用者的URL和我們請(qǐng)求的URL是否相等怪与，如果相等夺刑，那么就可以證明這個(gè)證書的確來自我們請(qǐng)求的服務(wù)器。
- 這樣證明了證書的確來自權(quán)威機(jī)構(gòu)+證書沒有被篡改+證書的來源可信分别，那么里面的服務(wù)器的公鑰就一定是可信的
