大家好，我是小林。

上周有位讀者在面字節時被問道這么一個問題：HTTPS 一定安全可靠嗎？

這個問題的場景是這樣的：客戶端通過瀏覽器向服務端發起 HTTPS 請求時，被「假基站」轉發到了一個「中間人服務器」，于是客戶端是和「中間人服務器」完成了 TLS 握手，然后這個「中間人服務器」再與真正的服務端完成 TLS 握手。

(資料圖片僅供參考)

具體過程如下：

客戶端向服務端發起 HTTPS 建立連接請求時，然后被「假基站」轉發到了一個「中間人服務器」，接著中間人向服務端發起 HTTPS 建立連接請求，此時客戶端與中間人進行 TLS 握手，中間人與服務端進行 TLS 握手；在客戶端與中間人進行 TLS 握手過程中，中間人會發送自己的公鑰證書給客戶端，客戶端驗證證書的真偽，然后從證書拿到公鑰，并生成一個隨機數，用公鑰加密隨機數發送給中間人，中間人使用私鑰解密，得到隨機數，此時雙方都有隨機數，然后通過算法生成對稱加密密鑰（A），后續客戶端與中間人通信就用這個對稱加密密鑰來加密數據了。在中間人與服務端進行 TLS 握手過程中，服務端會發送從 CA 機構簽發的公鑰證書給中間人，從證書拿到公鑰，并生成一個隨機數，用公鑰加密隨機數發送給服務端，服務端使用私鑰解密，得到隨機數，此時雙方都有隨機數，然后通過算法生成對稱加密密鑰（B），后續中間人與服務端通信就用這個對稱加密密鑰來加密數據了。后續的通信過程中，中間人用對稱加密密鑰（A）解密客戶端的 HTTPS 請求的數據，然后用對稱加密密鑰（B）加密 HTTPS 請求后，轉發給服務端，接著服務端發送 HTTPS 響應數據給中間人，中間人用對稱加密密鑰（B）解密 HTTPS 響應數據，然后再用對稱加密密鑰（A）加密后，轉發給客戶端。

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

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

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

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

如果用戶執意點擊「繼續瀏覽此網站」，相當于用戶接受了中間人偽造的證書，那么后續整個 HTTPS 通信都能被中間人監聽了。

所以，這其實并不能說 HTTPS 不夠安全，畢竟瀏覽器都已經提示證書有問題了，如果用戶堅決要訪問，那不能怪 HTTPS ，得怪自己手賤。

客戶端是如何驗證證書的？

接下來，詳細說一下實際中數字證書簽發和驗證流程。

如下圖圖所示，為數字證書簽發和驗證流程：

當服務端向 CA 機構申請證書的時候，CA 簽發證書的過程，如上圖左邊部分：

首先 CA 會把持有者的公鑰、用途、頒發者、有效時間等信息打成一個包，然后對這些信息進行 Hash 計算，得到一個 Hash 值；然后 CA 會使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對證書做了簽名；最后將 Certificate Signature 添加在文件證書上，形成數字證書；

客戶端校驗服務端的數字證書的過程，如上圖右邊部分：

首先客戶端會使用同樣的 Hash 算法獲取該證書的 Hash 值 H1；通常瀏覽器和操作系統中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內容，得到一個 Hash 值 H2 ；最后比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認為證書不可信。

但事實上，證書的驗證過程中還存在一個證書信任鏈的問題，因為我們向 CA 申請的證書一般不是根證書簽發的，而是由中間證書簽發的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

對于這種三級層級關系的證書的驗證過程如下：

客戶端收到 baidu.com 的證書后，發現這個證書的簽發者不是根證書，就無法根據本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信。于是，客戶端根據 baidu.com 證書中的簽發者，找到該證書的頒發機構是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 請求該中間證書。請求到證書后發現 “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發的，由于 “GlobalSign Root CA” 沒有再上級簽發機構，說明它是根證書，也就是自簽證書。應用軟件會檢查此證書有否已預載于根證書清單上，如果有，則可以利用根證書中的公鑰去驗證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，如果發現驗證通過，就認為該中間證書是可信的。“GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗證 baidu.com 證書的可信性，如果驗證通過，就可以信任 baidu.com 證書。

在這四個步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書?？偫▉碚f，由于用戶信任 GlobalSign，所以由 GlobalSign 所擔保的 baidu.com 可以被信任，另外由于用戶信任操作系統或瀏覽器的軟件商，所以由軟件商預載了根證書的 GlobalSign 都可被信任。

操作系統里一般都會內置一些根證書，比如我的 MAC 電腦里內置的根證書有這么多：

這樣的一層層地驗證就構成了一條信任鏈路，整個證書信任鏈驗證流程如下圖所示：

如果你的電腦中毒了，被惡意導入了中間人的根證書，那么在驗證中間人的證書的時候，由于你操作系統信任了中間人的根證書，那么等同于中間人的證書是合法的。

這種情況下，瀏覽器是不會彈出證書存在問題的風險提醒的。

這其實也不關 HTTPS 的事情，是你電腦中毒了才導致 HTTPS 數據被中間人劫持的。

所以，HTTPS 協議本身到目前為止還是沒有任何漏洞的，即使你成功進行中間人攻擊，本質上是利用了客戶端的漏洞（用戶點擊繼續訪問或者被惡意導入偽造的根證書），并不是 HTTPS 不夠安全。

為什么抓包工具能截取 HTTPS 數據？

抓包工具 Fiddler 之所以可以明文看到 HTTPS 數據，工作原理與中間人一致的。

對于 HTTPS 連接來說，中間人要滿足以下兩點，才能實現真正的明文代理:

中間人，作為客戶端與真實服務端建立連接這一步不會有問題，因為服務端不會校驗客戶端的身份；中間人，作為服務端與真實客戶端建立連接，這里會有客戶端信任服務端的問題，也就是服務端必須有對應域名的私鑰；

中間人要拿到私鑰只能通過如下方式：

去網站服務端拿到私鑰；去CA處拿域名簽發私鑰；自己簽發證書，切要被瀏覽器信任；

不用解釋，抓包工具只能使用第三種方式取得中間人的身份。

使用抓包工具進行 HTTPS 抓包的時候，需要在客戶端安裝 Fiddler 的根證書，這里實際上起認證中心（CA）的作用。

Fiddler 能夠抓包的關鍵是客戶端會往系統受信任的根證書列表中導入 Fiddler 生成的證書，而這個證書會被瀏覽器信任，也就是 Fiddler 給自己創建了一個認證中心 CA。

客戶端拿著中間人簽發的證書去中間人自己的 CA 去認證，當然認為這個證書是有效的。

如何避免被中間人抓取數據？

我們要保證自己電腦的安全，不要被病毒乘虛而入，而且也不要點擊任何證書非法的網站，這樣 HTTPS 數據就不會被中間人截取到了。

當然，我們還可以通過 HTTPS 雙向認證來避免這種問題。

一般我們的 HTTPS 是單向認證，客戶端只會驗證了服務端的身份，但是服務端并不會驗證客戶端的身份。

如果用了雙向認證方式，不僅客戶端會驗證服務端的身份，而且服務端也會驗證客戶端的身份。

服務端一旦驗證到請求自己的客戶端為不可信任的，服務端就拒絕繼續通信，客戶端如果發現服務端為不可信任的，那么也中止通信。

關鍵詞： 加密密鑰 數字證書 操作系統