HTTPS 一定是安全的嗎？

大家好，我是小林。

上周有位讀者在面位元組時被問道這麼一個問題：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 申請的證書一般不是根證書簽發的，而是由中間證書簽發的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

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

• 用戶端收到 http://baidu.com 的證書後，發現這個證書的簽發者不是根證書，就無法根據本地已有的根證書中的公鑰去驗證 http://baidu.com 證書是否可信。于是，用戶端根據 http://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” 證書中的公鑰去驗證 http://baidu.com 證書的可信性，如果驗證通過，就可以信任 http://baidu.com 證書。

在這四個步驟中，最開始用戶端隻信任根證書 GlobalSign Root CA 證書的，然後 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 http://baidu.com 證書，于是用戶端也信任 http://baidu.com 證書。總括來說，由于使用者信任 GlobalSign，是以由 GlobalSign 所擔保的 http://baidu.com 可以被信任，另外由于使用者信任作業系統或浏覽器的軟體商，是以由軟體商預載了根證書的 GlobalSign 都可被信任。

img

作業系統裡一般都會内置一些根證書，比如我的 MAC 電腦裡内置的根證書有這麼多：

img

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

img

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

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

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

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

為什麼抓包工具能截取 HTTPS 資料？

抓包工具 Fiddler 之是以可以明文看到 HTTPS 資料，工作原理與中間人一緻的。

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

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

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

1. 去網站服務端拿到私鑰；
2. 去CA處拿域名簽發私鑰；
3. 自己簽發證書，且被浏覽器信任；

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

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

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

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

如何避免被中間人抓取資料？

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

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

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

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

img

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

完！

更多網絡文章

]

• 網絡基礎篇
• • TCP/IP 網絡模型有哪幾層？
  • 鍵入網址到網頁顯示，期間發生了什麼？
  • Linux 系統是如何收發網絡包的？
• HTTP 篇
• • HTTP 常見面試題
  • HTTP/1.1如何優化？
  • HTTPS RSA 握手解析
  • HTTPS ECDHE 握手解析
  • HTTPS 如何優化？
  • HTTP/2 牛逼在哪？
  • HTTP/3 強勢來襲
  • 既然有 HTTP 協定，為什麼還要有 RPC？
• TCP 篇
• • TCP 三次握手與四次揮手面試題
  • TCP 重傳、滑動視窗、流量控制、擁塞控制
  • TCP 實戰抓包分析
  • TCP 半連接配接隊列和全連接配接隊列
  • 如何優化 TCP?
  • 如何了解是 TCP 面向位元組流協定？
  • 為什麼 TCP 每次建立連接配接時，初始化序列号都要不一樣呢？
  • SYN 封包什麼時候情況下會被丢棄？
  • 四次揮手中收到亂序的 FIN 包會如何處理？
  • 在 TIME_WAIT 狀态的 TCP 連接配接，收到 SYN 後會發生什麼？
  • TCP 連接配接，一端斷電和程序崩潰有什麼差別？
  • 拔掉網線後， 原本的 TCP 連接配接還存在嗎？
  • tcp_tw_reuse 為什麼預設是關閉的？
  • HTTPS 中 TLS 和 TCP 能同時握手嗎？
  • TCP Keepalive 和 HTTP Keep-Alive 是一個東西嗎？
  • TCP 有什麼缺陷？
  • 如何基于 UDP 協定實作可靠傳輸？
  • TCP 和 UDP 可以使用同一個端口嗎？
  • 服務端沒有 listen，用戶端發起連接配接建立，會發生什麼？
  • 沒有 accpet，可以建立 TCP 連接配接嗎？
  • 用了 TCP 協定，資料一定不會丢嗎？
• IP 篇
• • IP 基礎知識全家桶
  • ping 的工作原理
• 學習心得
• • 計算機網絡怎麼學？

微信搜尋公衆号：「小林coding」 ，回複「圖解」即可免費獲得「圖解網絡、圖解系統、圖解MySQL、圖解Redis」PDF 電子書