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

  為什么提示證書有問題？

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

  具體過程如下：

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

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

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

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

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

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

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

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