首先來(lái)看一種場(chǎng)景：小紅發(fā)信息約小明放學(xué)后去電影。
正常的信息流動(dòng)是這樣的：
1.小紅 -> 放學(xué)后去看電影吧？ -> 小明
2.小明 -> 好，校門(mén)口等我。 -> 小紅
但如果存在一個(gè)中間人把小紅和小明的信息攔截，并做了修改，信息流變成了下面這樣：
1.小紅 -> 放學(xué)后去看電影吧？-> 中間人（你） -> 今天上課有點(diǎn)累，放學(xué)我就回家了，不要等我。 -> 小明
2.小明 -> 好吧，好好休息。 -> 中間人（你） -> 不去了，放學(xué)后我就回家。 -> 小明
小紅以為小明不陪自己看電影，小明以為小紅放學(xué)就回家了，而你就找了個(gè)理由約上小紅去看電影了。
之所以會(huì)產(chǎn)生誤解，是因?yàn)樾〖t和小明沒(méi)辦法驗(yàn)證對(duì)方信息的真假，都以為收到了對(duì)方的正確信息，這是個(gè)典型的中間人攻擊的例子。
HTTPS正是要解決這個(gè)問(wèn)題，在HTTP傳輸層之上加了一個(gè)安全層（SSL或TLS協(xié)議實(shí)現(xiàn)），可以做到以下3點(diǎn)：
- **數(shù)據(jù)的保密性 **
- 校驗(yàn)雙方身份的真實(shí)性
- 數(shù)據(jù)的完整性
下面來(lái)看https是如果解決這3個(gè)問(wèn)題的。
一、數(shù)據(jù)的保密性
數(shù)據(jù)要保密，就需要對(duì)數(shù)據(jù)進(jìn)行加密。加密算法可以分為2類(lèi)，一類(lèi)是對(duì)稱(chēng)加密算法，另一類(lèi)是非對(duì)稱(chēng)加密算法。
對(duì)稱(chēng)加密算法，加密和解密使用相同的密鑰，優(yōu)點(diǎn)是加密速度快，缺點(diǎn)是如果密鑰泄露的話就無(wú)法做到保密了。常見(jiàn)的對(duì)稱(chēng)加密算法有DES、AES等。
非對(duì)稱(chēng)加密算法，又叫公開(kāi)密鑰加密。需要有2個(gè)密鑰，公鑰和私鑰，公鑰向所有人公開(kāi)，私鑰不公開(kāi)。用公鑰加密的數(shù)據(jù)只有私鑰才能解密；反之，用私鑰加密的數(shù)據(jù)只有公鑰才能解密。因?yàn)檫@種特性，非對(duì)稱(chēng)加密算法可以用來(lái)校驗(yàn)數(shù)字簽名，下面會(huì)具體講解。
很顯然，僅使用對(duì)稱(chēng)加密算法是不現(xiàn)實(shí)的，互聯(lián)網(wǎng)中通信的雙方大多是臨時(shí)建立的連接，不可能提前協(xié)商好密鑰，而且密鑰也要進(jìn)行傳輸，無(wú)法保證密鑰本身的安全性。
如果使用非對(duì)稱(chēng)加密，客戶(hù)端向服務(wù)器發(fā)送數(shù)據(jù)是安全的，客戶(hù)端用服務(wù)器的公鑰進(jìn)行加密，只有服務(wù)器用自己的私鑰才能解密。但如果服務(wù)器用私鑰對(duì)數(shù)據(jù)進(jìn)行加密，則所有人都可以用公鑰進(jìn)行解密，這是不安全的。
HTTPS的解決方案是這樣的：用非對(duì)稱(chēng)算法隨機(jī)加密出一個(gè)對(duì)稱(chēng)密鑰，然后雙方用對(duì)稱(chēng)密鑰進(jìn)行通信。具體來(lái)說(shuō)，就是客戶(hù)端生成一個(gè)隨機(jī)密鑰，用服務(wù)器的公鑰對(duì)這個(gè)密鑰進(jìn)行非對(duì)稱(chēng)加密，服務(wù)器用私鑰進(jìn)行解密，然后雙方就用這個(gè)對(duì)稱(chēng)密鑰來(lái)進(jìn)行數(shù)據(jù)加密了。
二、校驗(yàn)雙方身份的真實(shí)性
上面說(shuō)了加密，保證了數(shù)據(jù)不能被他人讀取，但通信的雙方怎樣校驗(yàn)對(duì)方的身份呢？HTTPS使用了數(shù)字證書(shū)，數(shù)字證書(shū)就是身份認(rèn)證機(jī)構(gòu)（Certificate Authority）蓋在數(shù)字身份證上的一個(gè)章或?。ɑ蛘哒f(shuō)加在數(shù)字身份證上的一個(gè)簽名），這一行為表示身份認(rèn)證機(jī)構(gòu)已認(rèn)定這個(gè)人。證書(shū)的合法性可以向CA驗(yàn)證。
數(shù)字證書(shū)主要包含以下信息：
- 證書(shū)頒發(fā)機(jī)構(gòu)
- 證書(shū)頒發(fā)機(jī)構(gòu)簽名
- 證書(shū)綁定的服務(wù)器域名
- 證書(shū)版本、有效期
- 簽名使用的加密算法（非對(duì)稱(chēng)算法，如RSA）
- 公鑰
客戶(hù)端收到服務(wù)器的響應(yīng)后，先向CA驗(yàn)證證書(shū)的合法性（根據(jù)證書(shū)的簽名、綁定的域名等信息），如果校驗(yàn)不通過(guò)，瀏覽器會(huì)中止連接，向用戶(hù)提示證書(shū)不安全。
需要提一點(diǎn)的是，證書(shū)的制作方法是公開(kāi)的，任何人都可以自己制作證書(shū)，所以有些公司不向CA申請(qǐng)，比如12306。但自己制作的證書(shū)是得不到CA認(rèn)證的，所以訪問(wèn)12306網(wǎng)站時(shí)，瀏覽器會(huì)有證書(shū)不合法的提示，如下圖，只有用戶(hù)選擇信任該網(wǎng)站時(shí)，才能繼續(xù)訪問(wèn)。
三、數(shù)據(jù)的完整性
網(wǎng)絡(luò)傳輸過(guò)程中需要經(jīng)過(guò)很多中間節(jié)點(diǎn)，雖然數(shù)據(jù)無(wú)法被解密，但可能被篡改，那如何校驗(yàn)數(shù)據(jù)的完整性呢？通過(guò)校驗(yàn)數(shù)字簽名，流程見(jiàn)下圖：
首先來(lái)了解下哈希算法，哈希算法能夠?qū)⑷我忾L(zhǎng)度的字符串轉(zhuǎn)化為固定長(zhǎng)度的字符串，該過(guò)程不可逆，可用來(lái)作數(shù)據(jù)完整性校驗(yàn)。
服務(wù)器在發(fā)送報(bào)文之前做了3件的事：
- 用哈希算法對(duì)報(bào)文提取定長(zhǎng)摘要
- 用私鑰對(duì)摘要進(jìn)行加密，作為數(shù)字簽名
- 將數(shù)字簽名附加到報(bào)文末尾發(fā)送給客戶(hù)端
客戶(hù)端接收到報(bào)文后：
- 用公鑰對(duì)服務(wù)器的數(shù)字簽名進(jìn)行解密
- 用同樣的算法重新計(jì)算出報(bào)文的數(shù)字簽名
- 比較解密后的簽名與自己計(jì)算的簽名是否一致，如果不一致，說(shuō)明數(shù)據(jù)被篡改過(guò)。
同樣，客戶(hù)端發(fā)送數(shù)據(jù)時(shí)，通過(guò)公鑰加密報(bào)文摘要，服務(wù)器用私鑰解密，用同樣的方法校驗(yàn)數(shù)據(jù)的完整性。
HTTPS通信的大致過(guò)程
客戶(hù)端將自己支持的加密算法發(fā)送給服務(wù)器，請(qǐng)求服務(wù)器證書(shū)；
服務(wù)器選取一組加密算法，并將證書(shū)返回給客戶(hù)端；
客戶(hù)端校驗(yàn)證書(shū)合法性，生成隨機(jī)對(duì)稱(chēng)密鑰，用公鑰加密后發(fā)送給服務(wù)器；
服務(wù)器用私鑰解密出對(duì)稱(chēng)密鑰，返回一個(gè)響應(yīng)，HTTPS連接建立完成；
隨后雙方通過(guò)這個(gè)對(duì)稱(chēng)密鑰進(jìn)行安全的數(shù)據(jù)通信。
思考
通過(guò)HTTPS，客戶(hù)端一旦發(fā)現(xiàn)證書(shū)不合法或者數(shù)據(jù)被篡改，就是中止連接，文章開(kāi)頭說(shuō)的中間人攻擊就無(wú)效了。
