自建CA本地搭建https

//第一步，為服務(wù)器端和客戶端準(zhǔn)備公鑰、私鑰
# 生成服務(wù)器端私鑰
openssl genrsa -out server.key 1024
# 生成服務(wù)器端公鑰
openssl rsa -in server.key -pubout -out server.pem

//第二步，生成 CA 證書
# 生成 CA 私鑰
openssl genrsa -out ca.key 1024
# X.509 Certificate Signing Request (CSR) Management.  ca證書簽名請求
#要求填寫一些資料。Common Name是能訪問的域名
openssl req -new -key ca.key -out ca.csr

# X.509 Certificate Data Management.    生成ca證書
openssl x509 -req -in ca.csr -signkey ca.key -out ca.crt

//第三步，生成服務(wù)器端證書
# 服務(wù)器端需要向 CA 機構(gòu)申請簽名證書，在申請簽名證書之前依然是創(chuàng)建自己的 CSR 文件
openssl req -new -key server.key -out server.csr
# 向自己的 CA 機構(gòu)申請證書，簽名過程需要 CA 的證書和私鑰參與，最終頒發(fā)一個帶有 CA 簽名的證書
openssl x509 -req -CA ca.crt -CAkey ca.key -CAcreateserial -in server.csr -out server.cr

之后再配置nginx的ssl即可

接下來通過WireShark抓包分析https協(xié)議的交互過程

1. 客戶端首先向服務(wù)器端發(fā)送一個 Client Hello 的 SSL 握手信息。

image.png

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

enter image description here

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

（2）Random（隨機數(shù)）和一個時間戳。

enter image description here

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

enter image description here

告訴 HTTPS 的服務(wù)器端，客戶端能支持上面這 26 種加密協(xié)議套裝上列出的算法，讓服務(wù)器選擇一個加密協(xié)議算法套裝。

（4）訪問的 Web 服務(wù)器的信息：

enter image description here

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

enter image description here

客戶端告訴服務(wù)器其支持 9 種簽名算法，讓服務(wù)器端自由選擇一個用于后續(xù)的加密通信。

2. HTTPS 服務(wù)器馬上給客戶端回復(fù) 4 條 SSL 握手信息

enter image description here

HTTPS 服務(wù)器馬上給客戶端回復(fù)了下面這 4 條 SSL 握手信息。

• Server Hello
• Certificate
• Server Key Exchange Server
• Hello Done

下面具體來看這 4 條由 HTTPS 服務(wù)器端發(fā)出的 4 條消息里面到底有什么內(nèi)容，其會告訴客戶端什么秘密和信息呢？

（1）Server Hello SSL 握手信息

enter image description here

其重點是把客戶端發(fā)送給服務(wù)器端的隨機數(shù)又給發(fā)送回去了，而且還生成了服務(wù)器端的 Session ID 并發(fā)送給客戶端，最后告訴客戶端，服務(wù)器端準(zhǔn)備選擇TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384作為秘鑰交互的加密協(xié)議套裝，該加密協(xié)議的套裝名字肯定出現(xiàn)在客戶端發(fā)送給服務(wù)器的支持的 26 個列表中，不信你可以翻回去對比一下。

（2）Certificate

enter image description here

SSL 服務(wù)器證書信息。在這條 HTTPS 服務(wù)器給客戶端回復(fù)消息 SSL 握手信息里面，其還會把服務(wù)器端的 SSL 證書發(fā)送給客戶端，從上圖的轉(zhuǎn)包信息中，我們能清晰地發(fā)現(xiàn)服務(wù)器端 SSL 證書的相關(guān)信息，比如，通用名字為 iis-web-01，組織單元為 it 等。

需要注意的是，如果是 SSL 的雙向認(rèn)證，服務(wù)器端也可以要求客戶端把 SSL 證書發(fā)送給服務(wù)器端（對應(yīng)的 SSL 握手消息名稱為：CertificateRequest），這個時候，客戶端就會把其 SSL 證書發(fā)送給服務(wù)器端，從而證明其就是服務(wù)器端信任的客戶端。

（3）Server Key Exchange 握手消息

enter image description here

HTTPS 服務(wù)器出大招了，告訴了客戶端其將會采用的 EC Diffie-Hellman 算法進(jìn)行 HTTPS 服務(wù)器和客戶端的秘鑰交換。具體什么是 EC Diffie-Hellman 算法，大家可以自行查閱資料，這里不再贅述，并提供了 EC Diffie-Hellman 算法使用到的服務(wù)器端的參數(shù)：

• 曲線類型：named_curve: secp256r1
• 公鑰信息
• 簽名的算法：rsa_pkcs1_sha1
• 簽名的信息

（4）Server Hello Done 握手信息

握手信息列表結(jié)束了。

enter image description here

3. HTTPS 客戶端馬上給服務(wù)器端回復(fù) 3 條 SSL 握手信息

當(dāng)客戶端收到服務(wù)器端的相關(guān)公鑰信息，SSL 證書以及摘要算法和摘要信息后，也不是無動于衷，而是積極的響應(yīng)了下面的 3 條 SSL 握手信息。

enter image description here

• Client Key Exchange
• Change Cipher Spec
• Encrypted Handshake Message

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

（1）Client Key Exchange 握手信息

enter image description here

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

• 對稱密碼的秘鑰
• 消息認(rèn)證碼的秘鑰
• 對稱密碼的 CBC 模式中使用的初始化向量（IV）

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

（2）Change Cipher Spec 握手信息

enter image description here

告訴服務(wù)器端，我要切換密碼了！

（3）Encrypted Handshake Message 握手信息

enter image description here

客戶端發(fā)出使用主密碼加密的結(jié)束信息，告訴服務(wù)器端：“秘鑰交換握手協(xié)議到此結(jié)束”。

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

enter image description here

這次輪到服務(wù)器端發(fā)送“Change Cipher Spec”消息了，服務(wù)器告訴客戶端：“好，現(xiàn)在我也要切換密碼了”。

服務(wù)器端用預(yù)備主密碼（Pre-Master secret）計算出的主秘鑰加密了一條信息，并發(fā)送給客戶端：“好的，秘鑰交換握手協(xié)議到此結(jié)束”。如果通信雙方都能把結(jié)束消息解密成功，說明主秘鑰已經(jīng)交換成功。就可以發(fā)送真正的用主密碼加密的應(yīng)用數(shù)據(jù)的信息了！

5. 服務(wù)端用對稱秘鑰把加密過的 HTML 網(wǎng)頁內(nèi)容發(fā)送給客戶端

enter image description here

服務(wù)器端用成功交換了秘鑰把加密過的 HTML 網(wǎng)頁內(nèi)容發(fā)送給客戶端，客戶端用以前收到過的對稱秘鑰進(jìn)行解密，HTTPS 通信協(xié)議圓滿結(jié)束。

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

上述具體流程如下圖所示

7042f5c3d9e3437d5b0b30b30f43c802.jpg

本文亦在微信公眾號【小道資訊】發(fā)布，歡迎掃碼關(guān)注！

image