有時(shí)候在瀏覽一些網(wǎng)站的時(shí)候，點(diǎn)進(jìn)去的時(shí)候不是直接顯示內(nèi)容，而是彈出來一個(gè)警告的界面，告訴你此網(wǎng)站的安全證書有問題，瀏覽器是建議你不要再繼續(xù)訪問了，當(dāng)然你也可以選擇繼續(xù)訪問。那么，你還敢繼續(xù)訪問一個(gè)”不安全“的網(wǎng)站嗎？會(huì)不會(huì)對(duì)你造成什么損失？本文從原理的角度來看看這個(gè)過程里究竟是發(fā)生了什么以及我們?nèi)绾稳ミx擇？

  為什么提示證書有問題？

  客戶端通過瀏覽器向服務(wù)端發(fā)起 HTTPS 請(qǐng)求時(shí)，被「假基站」轉(zhuǎn)發(fā)到了一個(gè)「中間人服務(wù)器」，于是客戶端是和「中間人服務(wù)器」完成了 TLS 握手，然后這個(gè)「中間人服務(wù)器」再與真正的服務(wù)端完成 TLS 握手。

  具體過程如下：

  1、客戶端向服務(wù)端發(fā)起 HTTPS 建立連接請(qǐng)求時(shí)，然后被「假基站」轉(zhuǎn)發(fā)到了一個(gè)「中間人服務(wù)器」，接著中間人向服務(wù)端發(fā)起 HTTPS 建立連接請(qǐng)求，此時(shí)客戶端與中間人進(jìn)行 TLS 握手，中間人與服務(wù)端進(jìn)行 TLS 握手；

  2、在客戶端與中間人進(jìn)行 TLS 握手過程中，中間人會(huì)發(fā)送自己的公鑰證書給客戶端，客戶端驗(yàn)證證書的真?zhèn)危缓髲淖C書拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給中間人，中間人使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過算法生成對(duì)稱加密密鑰（A），后續(xù)客戶端與中間人通信就用這個(gè)對(duì)稱加密密鑰來加密數(shù)據(jù)了。

  3、在中間人與服務(wù)端進(jìn)行 TLS 握手過程中，服務(wù)端會(huì)發(fā)送從 CA 機(jī)構(gòu)簽發(fā)的公鑰證書給中間人，從證書拿到公鑰，并生成一個(gè)隨機(jī)數(shù)，用公鑰加密隨機(jī)數(shù)發(fā)送給服務(wù)端，服務(wù)端使用私鑰解密，得到隨機(jī)數(shù)，此時(shí)雙方都有隨機(jī)數(shù)，然后通過算法生成對(duì)稱加密密鑰（B），后續(xù)中間人與服務(wù)端通信就用這個(gè)對(duì)稱加密密鑰來加密數(shù)據(jù)了。

  4、后續(xù)的通信過程中，中間人用對(duì)稱加密密鑰（A）解密客戶端的 HTTPS 請(qǐng)求的數(shù)據(jù)，然后用對(duì)稱加密密鑰（B）加密 HTTPS 請(qǐng)求后，轉(zhuǎn)發(fā)給服務(wù)端，接著服務(wù)端發(fā)送 HTTPS 響應(yīng)數(shù)據(jù)給中間人，中間人用對(duì)稱加密密鑰（B）解密 HTTPS 響應(yīng)數(shù)據(jù)，然后再用對(duì)稱加密密鑰（A）加密后，轉(zhuǎn)發(fā)給客戶端。

  從客戶端的角度看，其實(shí)并不知道網(wǎng)絡(luò)中存在中間人服務(wù)器這個(gè)角色。

  那么中間人就可以解開瀏覽器發(fā)起的 HTTPS 請(qǐng)求里的數(shù)據(jù)，也可以解開服務(wù)端響應(yīng)給瀏覽器的 HTTPS 響應(yīng)數(shù)據(jù)。相當(dāng)于，中間人能夠 “偷看” 瀏覽器與服務(wù)端之間的 HTTPS 請(qǐng)求和響應(yīng)的數(shù)據(jù)。

  但是要發(fā)生這種場(chǎng)景是有前提的，前提是用戶點(diǎn)擊接受了中間人服務(wù)器的證書。

  中間人服務(wù)器與客戶端在 TLS 握手過程中，實(shí)際上發(fā)送了自己偽造的證書給瀏覽器，而這個(gè)偽造的證書是能被瀏覽器（客戶端）識(shí)別出是非法的，于是就會(huì)提醒用戶該證書存在問題。