[[374308]]

本文轉載自微信公眾號「小林coding 」，作者小林coding。轉載本文請聯系小林coding公眾號。

我很早之前寫過一篇關于 HTTP 和 HTTPS 的文章，但對于 HTTPS 介紹還不夠詳細，只講了比較基礎的部分，所以這次我們再來深入一下 HTTPS，用實戰抓包的方式，帶大家再來窺探一次 HTTPS。

 

對于還不知道對稱加密和非對稱加密的同學，你先復習我以前的這篇文章「硬核!30 張圖解 HTTP 常見的面試題」，本篇文章默認大家已經具備了這些知識。

TLS 握手過程

HTTP 由于是明文傳輸，所謂的明文，就是說客戶端與服務端通信的信息都是肉眼可見的，隨意使用一個抓包工具都可以截獲通信的內容。

所以安全上存在以下三個風險：

• 竊聽風險，比如通信鏈路上可以獲取通信內容，用戶號容易沒。
• 篡改風險，比如強制植入垃圾廣告，視覺污染，用戶眼容易瞎。
• 冒充風險，比如冒充淘寶網站，用戶錢容易沒。

HTTPS 在 HTTP 與 TCP 層之間加入了 TLS 協議，來解決上述的風險。

 

TLS 協議是如何解決 HTTP 的風險的呢?

• 信息加密：HTTP 交互信息是被加密的，第三方就無法被竊取;
• 校驗機制：校驗信息傳輸過程中是否有被第三方篡改過，如果被篡改過，則會有警告提示;
• 身份證書：證明淘寶是真的淘寶網;

可見，有了 TLS 協議，能保證 HTTP 通信是安全的了，那么在進行 HTTP 通信前，需要先進行 TLS 握手。TLS 的握手過程，如下圖：

 

上圖簡要概述來 TLS 的握手過程，其中每一個「框」都是一個記錄(record)，記錄是 TLS 收發數據的基本單位，類似于 TCP 里的 segment。多個記錄可以組合成一個 TCP 包發送，所以通常經過「四個消息」就可以完成 TLS 握手，也就是需要 2個 RTT 的時延，然后就可以在安全的通信環境里發送 HTTP 報文，實現 HTTPS 協議。

所以可以發現，HTTPS 是應用層協議，需要先完成 TCP 連接建立，然后走 TLS 握手過程后，才能建立通信安全的連接。

事實上，不同的密鑰交換算法，TLS 的握手過程可能會有一些區別。

這里先簡單介紹下密鑰交換算法，因為考慮到性能的問題，所以雙方在加密應用信息時使用的是對稱加密密鑰，而對稱加密密鑰是不能被泄漏的，為了保證對稱加密密鑰的安全性，所以使用非對稱加密的方式來保護對稱加密密鑰的協商，這個工作就是密鑰交換算法負責的。

接下來，我們就以最簡單的 RSA 密鑰交換算法，來看看它的 TLS 握手過程。

RSA 握手過程

傳統的 TLS 握手基本都是使用 RSA 算法來實現密鑰交換的，在將 TLS 證書部署服務端時，證書文件中包含一對公私鑰，其中公鑰會在 TLS 握手階段傳遞給客戶端，私鑰則一直留在服務端，一定要確保私鑰不能被竊取。

在 RSA 密鑰協商算法中，客戶端會生成隨機密鑰，并使用服務端的公鑰加密后再傳給服務端。根據非對稱加密算法，公鑰加密的消息僅能通過私鑰解密，這樣服務端解密后，雙方就得到了相同的密鑰，再用它加密應用消息。

我用 Wireshark 工具抓了用 RSA 密鑰交換的 TLS 握手過程，你可以從下面看到，一共經歷來四次握手：

 

對應 Wireshark 的抓包，我也畫了一幅圖，你可以從下圖很清晰地看到該過程：

 

那么，接下來針對每一個 TLS 握手做進一步的介紹。

TLS 第一次握手

客戶端首先會發一個「Client Hello」消息，字面意思我們也能理解到，這是跟服務器「打招呼」。

 

消息里面有客戶端使用的 TLS 版本號、支持的密碼套件列表，以及生成的隨機數(Client Random)，這個隨機數會被服務端保留，它是生成對稱加密密鑰的材料之一。

TLS 第二次握手

當服務端收到客戶端的「Client Hello」消息后，會確認 TLS 版本號是否支持，和從密碼套件列表中選擇一個密碼套件，以及生成隨機數(Server Random)。

接著，返回「Server Hello」消息，消息里面有服務器確認的 TLS 版本號，也給出了隨機數(Server Random)，然后從客戶端的密碼套件列表選擇了一個合適的密碼套件。

 

可以看到，服務端選擇的密碼套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

這個密碼套件看起來真讓人頭暈，好一大串，但是其實它是有固定格式和規范的?；镜男问绞恰该荑€交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」， 一般 WITH 單詞前面有兩個單詞，第一個單詞是約定密鑰交換的算法，第二個單詞是約定證書的驗證算法。比如剛才的密碼套件的意思就是：

• 由于 WITH 單詞只有一個 RSA，則說明握手時密鑰交換算法和簽名算法都是使用 RSA;
• 握手后的通信使用 AES 對稱算法，密鑰長度 128 位，分組模式是 GCM;
• 摘要算法 SHA384 用于消息認證和產生隨機數;

就前面這兩個客戶端和服務端相互「打招呼」的過程，客戶端和服務端就已確認了 TLS 版本和使用的密碼套件，而且你可能發現客戶端和服務端都會各自生成一個隨機數，并且還會把隨機數傳遞給對方。

那這個隨機數有啥用呢?其實這兩個隨機數是后續作為生成「會話密鑰」的條件，所謂的會話密鑰就是數據傳輸時，所使用的對稱加密密鑰。

然后，服務端為了證明自己的身份，會發送「Server Certificate」給客戶端，這個消息里含有數字證書。

 

隨后，服務端發了「Server Hello Done」消息，目的是告訴客戶端，我已經把該給你的東西都給你了，本次打招呼完畢。

 

客戶端驗證證書

在這里剎個車，客戶端拿到了服務端的數字證書后，要怎么校驗該數字證書是真實有效的呢?

數字證書和 CA 機構

在說校驗數字證書是否可信的過程前，我們先來看看數字證書是什么，一個數字證書通常包含了：

• 公鑰;
• 持有者信息;
• 證書認證機構(CA)的信息;
• CA 對這份文件的數字簽名及使用的算法;
• 證書有效期;
• 還有一些其他額外信息;

那數字證書的作用，是用來認證公鑰持有者的身份，以防止第三方進行冒充。說簡單些，證書就是用來告訴客戶端，該服務端是否是合法的，因為只有證書合法，才代表服務端身份是可信的。

我們用證書來認證公鑰持有者的身份(服務端的身份)，那證書又是怎么來的?又該怎么認證證書呢?

為了讓服務端的公鑰被大家信任，服務端的證書都是由 CA (Certificate Authority，證書認證機構)簽名的，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 電腦里內置的根證書有這么多：

 

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

 

最后一個問題，為什么需要證書鏈這么麻煩的流程?Root CA 為什么不直接頒發證書，而是要搞那么多中間層級呢?

這是為了確保根證書的絕對安全性，將根證書隔離地越嚴格越好，不然根證書如果失守了，那么整個信任鏈都會有問題。

TLS 第三次握手

客戶端驗證完證書后，認為可信則繼續往下走。接著，客戶端就會生成一個新的隨機數 (pre-master)，用服務器的 RSA 公鑰加密該隨機數，通過「Change Cipher Key Exchange」消息傳給服務端。

 

服務端收到后，用 RSA 私鑰解密，得到客戶端發來的隨機數 (pre-master)。

至此，客戶端和服務端雙方都共享了三個隨機數，分別是 Client Random、Server Random、pre-master。

于是，雙方根據已經得到的三個隨機數，生成會話密鑰(Master Secret)，它是對稱密鑰，用于對后續的 HTTP 請求/響應的數據加解密。

生成完會話密鑰后，然后客戶端發一個「Change Cipher Spec」，告訴服務端開始使用加密方式發送消息。

 

然后，客戶端再發一個「Encrypted Handshake Message(Finishd)」消息，把之前所有發送的數據做個摘要，再用會話密鑰(master secret)加密一下，讓服務器做個驗證，驗證加密通信是否可用和之前握手信息是否有被中途篡改過。

 

可以發現，「Change Cipher Spec」之前傳輸的 TLS 握手數據都是明文，之后都是對稱密鑰加密的密文。

TLS 第四次握手

服務器也是同樣的操作，發「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果雙方都驗證加密和解密沒問題，那么握手正式完成。

最后，就用「會話密鑰」加解密 HTTP 請求和響應了。

RSA 算法的缺陷

使用 RSA 密鑰協商算法的最大問題是不支持前向保密。因為客戶端傳遞隨機數(用于生成對稱加密密鑰的條件之一)給服務端時使用的是公鑰加密的，服務端收到到后，會用私鑰解密得到隨機數。所以一旦服務端的私鑰泄漏了，過去被第三方截獲的所有 TLS 通訊密文都會被破解。

為了解決這一問題，于是就有了 DH 密鑰協商算法，這里簡單介紹它的工作流程。

 

客戶端和服務端各自會生成隨機數，并以此作為私鑰，然后根據公開的 DH 計算公示算出各自的公鑰，通過 TLS 握手雙方交換各自的公鑰，這樣雙方都有自己的私鑰和對方的公鑰，然后雙方根據各自持有的材料算出一個隨機數，這個隨機數的值雙方都是一樣的，這就可以作為后續對稱加密時使用的密鑰。

DH 密鑰交換過程中，即使第三方截獲了 TLS 握手階段傳遞的公鑰，在不知道的私鑰的情況下，也是無法計算出密鑰的，而且每一次對稱加密密鑰都是實時生成的，實現前向保密。

 

但因為 DH 算法的計算效率問題，后面出現了 ECDHE 密鑰協商算法，我們現在大多數網站使用的正是 ECDHE 密鑰協商算法，關于 ECDHE 握手的過程，將在下一篇揭曉，盡情期待哦。

原文鏈接：https://mp.weixin.qq.com/s/U9SRLE7jZTB6lUZ6c8gTKg