大家好，我是毛衣哥。上一期我們把 HTTP 扒光了，這一期來(lái)看看加了鎖的 HTTPS 又是怎么被一步步擰開(kāi)的。準(zhǔn)備好瓜子，七步拆完。上一篇我們把 HTTP 裸奔的慘狀全抖出來(lái)了。有人問(wèn)：那 HTTPS 一加密，中間人是不是就徹底沒(méi)轍了？答案是：要看它卡在哪一步。如果你不理解 TLS 握手每一步的精確內(nèi)容，你就永遠(yuǎn)不會(huì)知道中間人到底在哪個(gè)環(huán)節(jié)做了手腳。這篇可能會(huì)有點(diǎn)長(zhǎng)，但我保證這是你看過(guò)最詳細(xì)的 TLS 握手拆解。TLS 的目標(biāo)就兩個(gè)，記死了所有加密通信要解決的根本問(wèn)題永遠(yuǎn)只有兩個(gè)：第一：對(duì)方是它自稱的那個(gè)人嗎？（身份認(rèn)證）第二：怎么商量一把只有我倆知道的鑰匙？（密鑰協(xié)商）第一個(gè)問(wèn)題靠CA 證書(shū)。第二個(gè)問(wèn)題靠非對(duì)稱加密。TLS 握手就是同時(shí)完成這兩件事的過(guò)程。七步定乾坤：完整 TLS 1.2 握手拆解我在紙上畫(huà)了無(wú)數(shù)遍。TLS 1.2 的完整握手，不算兩端內(nèi)部的密鑰派生，正好七個(gè) TCP 包。第一步：ClientHello（客戶端發(fā)起通話）客戶端發(fā)一條明文消息給服務(wù)器。里面寫了什么？前 4 字節(jié)（時(shí)間戳）：GID // 0x474944 就是 ASCII 的 "GID"開(kāi)個(gè)玩笑。實(shí)際 TLS 的 ClientRandom 的前 4 字節(jié)是 Unix 時(shí)間戳：00 00 00 00 - 版本號(hào)（TLS 1.2 = 0x0303，這里只舉例）不對(duì)，我認(rèn)真說(shuō)：ClientHello 的精確結(jié)構(gòu)：1 字節(jié)：TLS 內(nèi)容類型（0x16 = Handshake） 2 字節(jié)：協(xié)議版本（0x0301 = TLS 1.0，但實(shí)際內(nèi)容看下面） 2 字節(jié)：長(zhǎng)度（指整個(gè) Handshake 消息的長(zhǎng)度） Handshake 消息體： 1 字節(jié)：握手類型（0x01 = ClientHello） 3 字節(jié)：長(zhǎng)度 2 字節(jié)：ClientHello 版本（0x0303 = TLS 1.2） 32 字節(jié)：ClientRandom（前 4 字節(jié)是 Unix 時(shí)間戳，后 28 字節(jié)純隨機(jī)） ……然后是一系列擴(kuò)展：關(guān)鍵內(nèi)容拆解：① 密碼套件列表客戶端列出一堆它支持的密碼套件，每個(gè)套件 2 字節(jié)。你猜有多少個(gè)？通常是 15-30 個(gè)。Cipher Suites (16 suites): TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ← 最強(qiáng)推薦 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ← 也很強(qiáng) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) ← 沒(méi)有 Forward Secrecy ……注意：密碼套件名字里每個(gè)段都有含義：密鑰交換算法：ECDHE、RSA、DHE證書(shū)簽名算法：ECDSA、RSA對(duì)稱加密算法：AES_128_GCM、AES_256_GCM、CHACHA20_POLY1305HMAC 算法：SHA256、SHA384② 32 字節(jié)的 ClientRandom這 32 個(gè)字節(jié)很重要。它不是隨便生成的隨機(jī)數(shù)——它跟后面 ServerRandom、Pre-Master Secret 一起，經(jīng)過(guò)一個(gè)偽隨機(jī)函數(shù)（PRF）推導(dǎo)出最終的 Master Secret。整個(gè)過(guò)程輸入的三個(gè)參數(shù)里，只要有一個(gè)變了，最終密鑰就完全不同。③ SNI 擴(kuò)展（這個(gè)最騷）Extension: server_name (type=0x0000, length=…) Server Name Indication extension Server Name list length: … Server Name Type: host_name (0x00) Server Name length: … Server Name: www.dumpany.cn看到了嗎？你訪問(wèn)的域名在 ClientHello 里是明文傳輸?shù)?！即使使?HTTPS，中間人也能從 ClientHello 的 SNI 擴(kuò)展里知道你正在訪問(wèn)哪個(gè)網(wǎng)站。這就解釋了為什么有些國(guó)家的防火墻能封掉特定網(wǎng)站——它不需要解密 TLS，只需要看 ClientHello 里的 SNI。域名是明文的。這也是為什么 ECH（Encrypted Client Hello，加密的 ClientHello）在最近的協(xié)議版本中被大力推進(jìn)——它要把這最后一塊明文的拼圖也給加密。④ ALPN 擴(kuò)展客戶端說(shuō)：“我支持這些應(yīng)用層協(xié)議：http/1.1、h2（HTTP/2）”。服務(wù)器會(huì)挑一個(gè)雙方都支持的。這在抓包里可以看到協(xié)商結(jié)果。第二步：ServerHello（服務(wù)器回禮）服務(wù)器回復(fù)，也是明文：1 字節(jié)：0x16（Handshake） 2 字節(jié)：0x0303（TLS 1.2） 2 字節(jié)：長(zhǎng)度 Handshake 內(nèi)容： 1 字節(jié)：0x02（ServerHello） 3 字節(jié)：長(zhǎng)度 2 字節(jié)：服務(wù)器選定的 TLS 版本（一般也是 0x0303） 32 字節(jié)：ServerRandom 1 字節(jié)：Session ID 長(zhǎng)度 可變：Session ID（如果有） 2 字節(jié)：選定的密碼套件（比如 0xc02f） 1 字節(jié)：選定的壓縮方法（0x00 = 不壓縮） 可變：擴(kuò)展關(guān)鍵：ServerRandom 也是一個(gè) 32 字節(jié)的隨機(jī)數(shù)。它的作用是保證即使兩個(gè)客戶端在同一毫秒發(fā)了同樣的 Pre-Master Secret（幾乎不可能），最終的會(huì)話密鑰也完全不同。第三步：Certificate（服務(wù)器亮出身份證）這一步信息量極大，是整個(gè) TLS 握手最值得細(xì)細(xì)品味的消息。服務(wù)器發(fā)來(lái)自己的證書(shū)鏈——注意不是只有一個(gè)證書(shū)，是多個(gè)。正常情況下的證書(shū)鏈：證書(shū) 1（葉子證書(shū) / 服務(wù)器證書(shū)） Version: 3 (0x02) Serial Number: 04:79:fb:8a:... Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=R3 ← 誰(shuí)簽發(fā)了我？（中間 CA 名） Validity Not Before: Jul 20 01:00:00 2026 GMT Not After : Oct 18 01:00:00 2026 GMT Subject: CN=dumpany.cn ← 這個(gè)證書(shū)是發(fā)給誰(shuí)的 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) ... X509v3 extensions: X509v3 Subject Alternative Name: ← 這就是 SAN 列表 DNS:dumpany.cn, DNS:www.dumpany.cn ← 所有受保護(hù)的域名 CA:FALSE ← 這個(gè)證書(shū)不能做 CA ... 證書(shū) 2（中間 CA 證書(shū)） Version: 3 (0x02) Serial Number: ... Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1 ← 根證書(shū)簽發(fā)了我 Subject: C=US, O=Let's Encrypt, CN=R3 ← 我就是 Let's Encrypt 的中間 CA X509v3 extensions: CA:TRUE ← 這個(gè)證書(shū)是 CA（可以簽發(fā)其他證書(shū)） ... 證書(shū) 3（根證書(shū)——一般不發(fā)送，因?yàn)闉g覽器已經(jīng)有了）在這個(gè)消息里，中間人能讀到什么？明文！在 TLS 1.2 里，Certificate 消息是明文的。中間人可以看到完整的證書(shū)內(nèi)容——包括你用的哪個(gè) CA、證書(shū)什么時(shí)候過(guò)期、你的公鑰是多少。這也意味著：在 TLS 1.2 里，中間人在握手階段就能判斷你訪問(wèn)的是哪個(gè)網(wǎng)站——即使 SNI 被加密了（實(shí)際上沒(méi)有），從證書(shū)的 CN 或 SAN 也能讀到域名。這也是 TLS 1.3 要改善的地方之一——在 1.3 里，Certificate 消息是加密的。第四步：ServerKeyExchange（如果有的話）這一步只在使用了 DHE/ECDHE 密鑰交換時(shí)才出現(xiàn)。如果是 RSA 密鑰交換，沒(méi)有這一步。服務(wù)器發(fā)了什么：1 字節(jié)：0x0c（ServerKeyExchange） 3 字節(jié)：長(zhǎng)度 內(nèi)容： 1 字節(jié)：橢圓曲線類型（named_curve = 0x03） 2 字節(jié)：曲線名稱（x25519 = 0x001d，或 secp256r1 = 0x0017） 1 字節(jié)：公鑰長(zhǎng)度 可變：服務(wù)器 DH 公鑰 2 字節(jié)：簽名長(zhǎng)度 可變：簽名（用自己的證書(shū)私鑰簽的）這一步是 ECDHE 的核心所在。服務(wù)器說(shuō)：“這是我的 DH 公鑰，你要的曲線是 x25519，參數(shù)都在明文中。你驗(yàn)一下簽名，確認(rèn)是我發(fā)的，沒(méi)人改過(guò)?！睘槭裁催@一步對(duì)中間人至關(guān)重要？如果中間人想冒充服務(wù)器，它必須在這一步之后，自己也生成一對(duì) DH 公私鑰，把自己的公鑰發(fā)給客戶端。但是——中間人用自己的私鑰簽名后，客戶端用真正的服務(wù)器的公鑰（從第三步的證書(shū)里拿到的）去驗(yàn)證簽名時(shí)，會(huì)失敗。因?yàn)楹灻玫氖侵虚g人的私鑰，不是服務(wù)器的私鑰。這就是 CA 信任鏈在 ECDHE 中的關(guān)鍵作用。第五步：ClientKeyExchange（客戶端奉上鑰匙）客戶端發(fā)：1 字節(jié)：0x10（ClientKeyExchange） 3 字節(jié)：長(zhǎng)度 內(nèi)容：根據(jù)不同的密鑰交換算法，內(nèi)容完全不同RSA 模式（現(xiàn)在很少用了）：客戶端生成 48 字節(jié)的 Pre-Master Secret：Pre-Master Secret: 2 字節(jié)：客戶端支持的 TLS 版本（比如 0x0303） 46 字節(jié)：純隨機(jī)數(shù)然后用服務(wù)器的公鑰加密這 48 字節(jié)，發(fā)過(guò)去。服務(wù)器用自己的私鑰解密，拿到 Pre-Master Secret。DH/ECDHE 模式（現(xiàn)代主流，TLS 1.3 強(qiáng)制用）：客戶端發(fā)送自己的 DH 公鑰。然后雙方各自用自己的私鑰 + 對(duì)方的公鑰，計(jì)算出相同的 Pre-Master Secret。關(guān)鍵區(qū)別：RSA 模式下，Pre-Master Secret 是"客戶端生成 → 加密發(fā)送 → 服務(wù)器解密"——它在網(wǎng)絡(luò)上傳輸過(guò)（雖然是加密的）ECDHE 模式下，Pre-Master Secret 是"雙方各自用對(duì)方的公鑰 + 自己的私鑰在本地計(jì)算出"——它從未在網(wǎng)絡(luò)上傳輸過(guò)第二個(gè)模式的最大優(yōu)勢(shì)：Forward Secrecy（前向安全性）。什么意思呢？如果用 RSA 模式，五年后攻擊者拿到了服務(wù)器的私鑰——它可以解密五年前保存的加密的 Pre-Master Secret，進(jìn)而推算出五年前的會(huì)話密鑰，解密五年前的通信內(nèi)容。如果用 ECDHE 模式，五年前的通信的 DH 臨時(shí)密鑰早銷毀了。即使拿到了服務(wù)器的主私鑰，也計(jì)算不出過(guò)去的 Pre-Master Secret。也就解密不了過(guò)去的通信。這就是"前向安全"——確保即使今天被攻破，過(guò)去的通信仍然安全。第六步：Change Cipher Spec + Finished雙方各自做了一大堆數(shù)學(xué)計(jì)算：ClientRandom + ServerRandom + Pre-Master Secret → PRF（偽隨機(jī)函數(shù)） → Master Secret（48 字節(jié)） → 密鑰導(dǎo)出函數(shù) → 6 個(gè)會(huì)話密鑰： - 客戶端寫密鑰（AES-128-GCM 的 key） - 服務(wù)端寫密鑰 - 客戶端 IV - 服務(wù)端 IV - 客戶端 HMAC 密鑰 - 服務(wù)端 HMAC 密鑰這個(gè)過(guò)程在代碼里的偽代碼表示：// TLS 1.2 密鑰派生偽代碼 function derive_keys(client_random[32], server_random[32], premaster_secret[48]): // 第一步：用 PRF 從 Pre-Master Secret 派生出 Master Secret master_secret[48] = PRF( secret: premaster_secret, label: "master secret", seed: client_random + server_random ) // 第二步：用 PRF 從 Master Secret 派生出 6 個(gè)會(huì)話密鑰 key_b