字節一面:HTTPS 一定安全可靠嗎?

2022.08.24

字節一面:HTTPS 一定安全可靠嗎?

HTTPS 協議本身到目前為止還是沒有任何漏洞的,即使你成功進行中間人攻擊,本質上是利用了客戶端的漏洞(用戶點擊繼續訪問或者被惡意導入偽造的根證書),並不是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 申請的證書一般不是根證書籤發的,而是由中間證書籤發的,比如百度的證書,從下圖你可以看到,證書的層級有三級:

圖片

對於這種三級層級關係的證書的驗證過程如下:

  • 客戶端收到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 證書。總括來說,由於用戶信任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 是單向認證,客戶端只會驗證了服務端的身份,但是服務端並不會驗證客戶端的身份。

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

圖片

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