當前位置:
首頁 > 最新 > 你真的了解HTTPS的加密過程嗎

你真的了解HTTPS的加密過程嗎

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

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

本站內容充實豐富,博大精深,小編精選每日熱門資訊,隨時更新,點擊「搶先收到最新資訊」瀏覽吧!


請您繼續閱讀更多來自 小道視野 的精彩文章:

帶你看透HTTP協議

TAG:小道視野 |