1. 自建CA本地搭建HTTPS

然後配置nginx的ssl，搭建https服務

2. 接下來通過WireShark抓包分析HTTPS協議的交互過程

1. 客戶端首先向伺服器端發送一個 Client Hello 的 SSL 握手信息。

雖然只有 Client Hello 兩個單詞，但是其消息體裡面包含了豐富的信息，我們在 WireShark 上選擇這行記錄，並雙擊，其裡面包含了下面的一些主要信息。

（1）Handshake Type：Client Hello（握手類型）。

（2）Random（隨機數）和一個時間戳。

（3）客戶端支持的加密協議套裝。

告訴 HTTPS 的伺服器端，客戶端能支持上面這 26 種加密協議套裝上列出的演算法，讓伺服器選擇一個加密協議演算法套裝。

（4）訪問的 Web 伺服器的信息：

（5）客戶端支持的簽名演算法：

客戶端告訴伺服器其支持 9 種簽名演算法，讓伺服器端自由選擇一個用於後續的加密通信。

2. HTTPS 伺服器馬上給客戶端回復 4 條 SSL 握手信息

HTTPS 伺服器馬上給客戶端回復了下面這 4 條 SSL 握手信息。

Server Hello

Certificate

Server Key Exchange Server

Hello Done

下面具體來看這 4 條由 HTTPS 伺服器端發出的 4 條消息裡面到底有什麼內容，其會告訴客戶端什麼秘密和信息呢？

（1）Server Hello SSL 握手信息

其重點是把客戶端發送給伺服器端的隨機數又給發送回去了，而且還生成了伺服器端的 Session ID 並發送給客戶端，最後告訴客戶端，伺服器端準備選擇作為秘鑰交互的加密協議套裝，該加密協議的套裝名字肯定出現在客戶端發送給伺服器的支持的 26 個列表中，不信你可以翻回去對比一下。

（2）Certificate

SSL 伺服器證書信息。在這條 HTTPS 伺服器給客戶端回復消息 SSL 握手信息裡面，其還會把伺服器端的 SSL 證書發送給客戶端，從上圖的轉包信息中，我們能清晰地發現伺服器端 SSL 證書的相關信息，比如，通用名字為 iis-web-01，組織單元為 it 等。

需要注意的是，如果是 SSL 的雙向認證，伺服器端也可以要求客戶端把 SSL 證書發送給伺服器端（對應的 SSL 握手消息名稱為：CertificateRequest），這個時候，客戶端就會把其 SSL 證書發送給伺服器端，從而證明其就是伺服器端信任的客戶端。

（3）Server Key Exchange 握手消息

HTTPS 伺服器出大招了，告訴了客戶端其將會採用的 EC Diffie-Hellman 演算法進行 HTTPS 伺服器和客戶端的秘鑰交換。具體什麼是 EC Diffie-Hellman 演算法，大家可以自行查閱資料，這裡不再贅述，並提供了 EC Diffie-Hellman 演算法使用到的伺服器端的參數：

曲線類型：

公鑰信息

簽名的演算法：

簽名的信息

（4）Server Hello Done 握手信息

握手信息列表結束了。

3. HTTPS 客戶端馬上給伺服器端回復 3 條 SSL 握手信息

當客戶端收到伺服器端的相關公鑰信息，SSL 證書以及摘要演算法和摘要信息後，也不是無動於衷，而是積極的響應了下面的 3 條 SSL 握手信息。

Client Key Exchange

Change Cipher Spec

Encrypted Handshake Message

那麼這三條 SSL 的握手信息將會透露出什麼？客戶端到底想告訴伺服器端什麼？讓我們一一分解。

（1）Client Key Exchange 握手信息

其給伺服器端發送了一條用伺服器端公鑰加密的信息，其裡面就包含了預備主密碼（Pre-Master secret），其是由客戶端隨機生成，之後會被用作生成主密碼的種子。根據預備密碼，伺服器和客戶端會計算出相同的主密碼（Master secret），然後根據主密碼生成下面的比特序列（秘鑰素材）。

對稱密碼的秘鑰

消息認證碼的秘鑰

對稱密碼的 CBC 模式中使用的初始化向量（IV）

需要注意的是，Client 秘鑰交換的方式主要有兩種，一種是通過 RSA 公鑰密碼進行交互，這個時候客戶端會在發送 ClientKeyExchange 消息時，將經過加密的預備主密碼一起發送給伺服器。當使用 Diffie-Hellman 交換秘鑰的時候，客戶端會在發送 ClientKeyExchange 消息時，將 Diffie-Hellman 公開值（Pub Key）一起發送給伺服器，根據這個值，客戶端和伺服器會各自生成預備主密碼，而且更加這個預備主密碼能夠生成相同的對稱主密碼。

（2）Change Cipher Spec 握手信息

告訴伺服器端，我要切換密碼了！

（3）Encrypted Handshake Message 握手信息

客戶端發出使用主密碼加密的結束信息，告訴伺服器端：「秘鑰交換握手協議到此結束」。

4. HTTPS 服務端馬上給客戶端回復 2 條 SSL 握手信息

這次輪到伺服器端發送「Change Cipher Spec」消息了，伺服器告訴客戶端：「好，現在我也要切換密碼了」。

伺服器端用預備主密碼（Pre-Master secret）計算出的主秘鑰加密了一條信息，並發送給客戶端：「好的，秘鑰交換握手協議到此結束」。如果通信雙方都能把結束消息解密成功，說明主秘鑰已經交換成功。就可以發送真正的用主密碼加密的應用數據的信息了！

5. 服務端用對稱秘鑰把加密過的 HTML 網頁內容發送給客戶端

伺服器端用成功交換了秘鑰把加密過的 HTML 網頁內容發送給客戶端，客戶端用以前收到過的對稱秘鑰進行解密，HTTPS 通信協議圓滿結束。

上面的步驟只是把我當前環境下抓取到的使用 TL S1.2 協議規範進行了 HTTPS 通信原理和過程的梳理和解釋，在不同的環境下，其通信過程會有一些差異，比如，如果配置了雙向 SSL 認證，其 SSL 伺服器端還會要求客戶端把客戶端的證書發送到服務端，從而驗證客戶端是否是可信任的，另外在進行主密碼交換的過程中，也可能採用 RSA 公鑰密碼，而不是 Diffie-Hellman，此時，其 SSL 握手消息會有所不同，但是整體的流程和交互過程思路基本上保持相同。

上述具體流程如下圖所示

GIF

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！