HTTPS 是建立在 SSL/TLS 傳輸層安全協議之上的一種 HTTP 協議，相當于 HTTPS = HTTP + SSL/TLS。第一篇文章 “HTTPS - 通俗易懂的闡述 HTTPS 協議，解決面試難題” 更多是理論上的一些闡述，能解決一些面試及常見問題，例如 “SSL/TLS” 的關系是什么?文中都有介紹。本文通過對一次 TLS 握手過程的數據抓包分析做為切入點，希望能進一步的幫助大家理解 HTTPS 原理。
TLS 協議
TLS 是一種密碼學協議，保證了兩個端點之間的會話安全，一種最好的學習方法是使用抓包工具，捕獲網絡數據包，基于這些真實的數據包能夠有一些直觀的感受，例如：Wireshark，它可以捕獲 HTTP、TCP、TLS 等各種網絡協議數據包，是我們學習的好工具。
TLS 定義了四個核心子協議：握手協議 (handshake protocol)、密鑰規格變更協議 (change cipher spec protocol)、應用數據協議 (application data protocol) 和警報協議 (alert protocol)，這里最主要、最復雜是“握手協議”，協商對稱密碼就是在該協議中完成的。
來源：https://hpbn.co/assets/diagrams/9873c7441be06e0b53a006aac442696c.svg
握手過程圖示
參考 “網絡協議那些事兒 - 如何抓包并破解 HTTPS 加密數據?”，本文是抓取的 www.imooc.com 網站數據包，基于 TLS v1.2 協議未對數據包做解密處理。
下圖展示了 HTTPS 鏈接建立、TLS 握手協議里參數傳遞、證書驗證、協商對稱密鑰的過程，更詳細的內容，下文會介紹。
tls-1-2-full-handshake.jpg
握手協議
握手協議是 TLS 協議中最復雜的一部分，在這個過程中雙方會協商鏈接參數(TLS 版本號、隨機數等)并完成身份驗證。里面可能會存在幾種情況：完整握手，對服務器進行身份驗證、恢復之前的會話采用的簡短握手、對客戶端和服務器都進行身份驗證握手，下文以完整握手為例。
在建立 TCP 鏈接之后，每一個 TLS 鏈接都會以握手協議開始，完整握手是客戶端與服務器之前未建立會話，在第一次會話時會經歷一次完整的握手。
Client Hello
在一次新的握手協議中，客戶端(瀏覽器)首先發出的一條消息是 “Client Hello”，告訴服務器我將給你傳遞這些數據：
- Version：客戶端支持的最佳協議版本號。
- Random：客戶端提供給服務器的隨機數，在每次握手中都會重新生成，這個隨機數用于后續生成密鑰。
- Session ID：會話 ID 在第一次鏈接時該字段是空的，表示客戶端并不希望恢復某個已存在的會話。
- Cipher Suites：客戶端所支持的所有秘密套件，按優先級順序排列。
- Handshake Protocol: Client Hello
- Handshake Type: Client Hello (1)
- Length: 223
- Version: TLS 1.2 (0x0303)
- Random: b0fcb3aca27c6de8b0e4f146b92d33f24e6a671e62f8f6f669aabbfc19bb4326
- Session ID Length: 0
- Cipher Suites Length: 92
- Cipher Suites (46 suites)
- Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
- Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
- Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
- ...
Server Hello
“Server Hello” 是服務器在收到客戶端 “Client Hello” 之后的一個回應，告訴客戶端服務器的協議版本、服務器也會給出一個隨機數 Random 用于后續生成密鑰，Cipher Suite 是從客戶端 “Client Hello” 消息的 Cipher Suites 里選擇的一個密碼套件。
- Handshake Protocol: Server Hello
- Handshake Type: Server Hello (2)
- Length: 89
- Version: TLS 1.2 (0x0303)
- Random: 616d836f609800aaa1713462f61d50cc6472c45b54c0ac58dd52b9db4d555f6f
- Session ID Length: 32
- Session ID: 279fb99351526e29a4ce41af4cbff5575933e5c45dff7a2016a16cdf414f22c2
- Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
了解密碼套件構成
Certificate, Server Key Exchange, Server Hello Done
在 “Server Hello” 之后，服務器緊跟隨著發出 “Certificate, Server Key Exchange, Server Hello Done” 這三個消息告知客戶端。
Certificate(發送服務器證書信息到客戶端)
證書信息，典型的 Certificate 消息用于攜帶服務器 X.509 證書鏈，一個接一個組合而成，主證書第一個，之后中間證書和根證書，服務器的公鑰也包含在證書信息中。
- Handshake Protocol: Certificate
- Handshake Type: Certificate (11)
- Length: 2781
- Certificates Length: 2778
- Certificates (2778 bytes)
- Certificate Length: 1407
- Certificate: 3082057b30820463a0030201020210040f1f824b17ca53814dc5c6f4c6a0a8300d06092a… (id-at-commonName=*.imooc.com)
- Certificate Length: 1365
- Certificate: 3082055130820439a003020102021007983603ade39908219ca00c27bc8a6c300d06092a… (id-at-commonName=RapidSSL TLS DV RSA Mixed SHA256 2020 CA-1,id-at-organizationName=DigiCert Inc,id-at-countryName=US)
這個證書鏈在瀏覽器地址欄點擊域名前面的 “小鎖”，可看到如下信息，最上面是根證書、中間(RapidSSL)是中級證書頒發機構、*.imooc.com 這個是 CA 頒發給我們的域名證書。
Server Key Exchange(密鑰交換)
“Server Key Exchange” 消息是攜帶密鑰交換算法需要的額外數據，目的是計算主密鑰需要的另一個值：“預主密鑰(premaster secret)”。
不同的算法套件對應的消息內容也是不同的，下面 EC Diffie-Hellman(簡稱 ECDHE)就是密鑰交換算法，這個對應 “Server Hello” 消息中選擇的密碼套件 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 中的 ECDHE。
下面 Server Params 中的 Curve Type 表示曲線類型，本次選中的橢圓曲線名稱為 named_curve：secp256r1，再確定基點 G，此時還會選擇生成一個隨機數做為服務端橢圓曲線的私鑰，存放到本地，再根據基點 G 和橢圓曲線的私鑰計算出橢圓曲線公鑰(這里的橢圓曲線公/私鑰都是臨時的，只對本次鏈接生效)，名字為 Pubkey 傳遞給客戶端。
為了確保橢圓曲線公鑰信息不被篡改，將 Server Params 與客戶端和服務器隨機值連在一起使用私鑰簽名，客戶端從證書中獲得服務器的公鑰，就可驗證是否來自服務器。客戶端和服務器的隨機值對于一次握手是唯一的，這也意味著攻擊者無法重復利用該簽名。
- Handshake Protocol: Server Key Exchange
- Handshake Type: Server Key Exchange (12)
- Length: 329
- EC Diffie-Hellman Server Params
- Curve Type: named_curve (0x03)
- Named Curve: secp256r1 (0x0017)
- Pubkey Length: 65
- Pubkey: 049c1c4eaa2ab8ae7b54482efc5d07e2b191174d804d660be07ded253c86f9bc5cd24f34…
- Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
- Signature Hash Algorithm Hash: SHA512 (6)
- Signature Hash Algorithm Signature: RSA (1)
- Signature Length: 256
- Signature: 5b9b1a750f0168f0a57852b4a77c14c351c5b97d7eb4a470fa8e3cf9e385cf7ac16f056f…
不同的密鑰交換算法，生成預主密鑰的方式也不同，我們這里的示例以 ECDHE 為主，還有一種密鑰交換算法是 RSA，它的密鑰交換過程很簡單，由客戶端生成預主密鑰，為 46 字節的隨機數，使用服務器的公鑰加密，經過“Client Key Exchange” 消息發送到服務端，服務端再用私鑰就可解密出這個預主密鑰。
基于 RSA 的密鑰交換算法被認為存在嚴重的漏洞威脅，任何能夠接觸到私鑰的人(例如，由于政治、賄賂、強行進入等)都可恢復預主密鑰，進而構建相同的主密鑰，最終密鑰泄漏就可解密之前記錄的所有流量了。這種密鑰交換算法正在被支持前向保密保密的其它算法替代，例如，我們示例中的 ECDHE 算法在密鑰交換時，每個鏈接使用的主密鑰相互獨立，如果出現問題也只是影響到當前會話，不能用于追溯解密任何其它的流量。
Server Hello Done
“Server Hello Done” 表示服務器已將握手消息需要的數據都發送完畢。之后就是等待客戶端的回應。
- Handshake Protocol: Server Hello Done
- Handshake Type: Server Hello Done (14)
- Length: 0
Client Key Exchange(客戶端發送給服務器的密鑰交換信息)
“Client Key Exchange” 的消息也是攜帶密鑰交換需要的額外數據，不過這一次是客戶端發送給服務端的，Client Params 里面提供了客戶端生成的臨時橢圓曲線公鑰信息。
- Handshake Protocol: Client Key Exchange
- Handshake Type: Client Key Exchange (16)
- Length: 66
- EC Diffie-Hellman Client Params
- Pubkey Length: 65
- Pubkey: 04c64110c2838d112d8fbc8a85a2c2b3b596e70d6ff9198330801df93ce9737432eeabe6…
客戶端驗證證書和計算密鑰
現在一次 TCP 往返結束了，客戶端拿到了服務器的證書、Server Random、Server Params，現在客戶端需要驗證證書合法性和計算一些加密信息。
驗證服務器發來的證書合法性
客戶端收到服務器的響應信息，驗證證書的合法性，可回顧上一節 深入淺出 HTTPS 原理篇。如果證書校驗通過繼續往下走。
計算預主密鑰
上面也提了，在 “Server Key Exchange” 消息中，服務器對 Server Params 用私鑰做了簽名，客戶端要從證書中獲得服務器公鑰，驗證參數是否來自期望的服務器，這也是身份驗證。
身份驗證成功之后，得到 Server Params 參數，而 Server Params 參數里包含了 “服務器密鑰交換消息” 中生成的臨時公鑰、secp256r1 橢圓曲線算法，現在客戶端使用 secp256r1 算法用這個臨時公鑰和客戶端自己生成的臨時私鑰相乘計算出預主密鑰(premaster secret)。
計算主密鑰
現在客戶端手里已經有了 Client Random、Server Random、Premaster Secret 三個隨機參數，調用 PRF 偽隨機函數函數生成 48 字節(384 位)主密鑰。
- master_secret = PRF(pre_master_secret, "master secret",
- ClientHello.random + ServerHello.random)
構建會話密鑰
上面的主密鑰并不是最終的會話密鑰，最終的會話密鑰使用 PRF 偽隨機函數傳入主密鑰、客戶端隨機數、服務端隨機數生成。
- key_block = PRF(master_secret, "key expansion", server_random + client_random)
這個最終的會話密鑰包括：對稱加密密鑰(symmetric key)、消息認證碼密鑰(mac key)、初始化項量(iv key，只在必要時生成)。
客戶端發出 Change Cipher Spec, Encrypted Handshake Message
當客戶端完成密鑰計算操作后，還要給服務器發送切換加密模式、驗證會話密碼消息。
Change Cipher Spec
“Change Cipher Spec” 消息表示客戶端已生成加密密鑰，并切換到加密模式。
- TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
- Content Type: Change Cipher Spec (20)
- Version: TLS 1.2 (0x0303)
- Length: 1
- Change Cipher Spec Message
注意：“Change Cipher Spec” 不屬于握手協議，它是另一種密鑰規格變更協議。
Encrypted Handshake Message
這個是將之前所有的握手數據做一個摘要，再用最后協商好的對稱加密算法對數據做加密，通過 “Encrypted Handshake Message” 消息發送到服務器進行校驗，這個對稱加密密鑰是否成功。
- TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
- Content Type: Handshake (22)
- Version: TLS 1.2 (0x0303)
- Length: 60
- Handshake Protocol: Encrypted Handshake Message
服務器計算密鑰
服務器在收到客戶端 “Client Key Exchange” 消息后，這時可以拿到 Client Random、Server Random、Client Params，先計算出預主密鑰后，再分別計算出主密鑰和最終的會話密鑰，這塊可參考客戶端計算密鑰一樣的。
服務器發出 Change Cipher Spec, Encrypted Handshake Message
Change Cipher Spec
服務器發出 “Change Cipher Spec” 消息告訴客戶端，服務端已生成密鑰，請求客戶端切換加密模式。
- TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
- Content Type: Change Cipher Spec (20)
- Version: TLS 1.2 (0x0303)
- Length: 1
Encrypted Handshake Message
“Encrypted Handshake Message” 這條消息也是服務器對握手的所有數據用協商好的對稱加密算法加密，供客戶端校驗。
如果對抓取后的報文做解密，這里看到的是 “Finished” 消息。
- TLSv1.2 Record Layer: Handshake Protocol: Encrypted Handshake Message
- Content Type: Handshake (22)
- Version: TLS 1.2 (0x0303)
- Length: 40
- Handshake Protocol: Encrypted Handshake Message
應用數據協議
整個握手過程完畢之后，我們會看到應用數據協議 “Application Data Protocol: http-over-tls”，之后我們的客戶端/服務端建立一個安全通信隧道，就可以發送應用程序數據了。
- TLSv1.2 Record Layer: Application Data Protocol: http-over-tls
- Content Type: Application Data (23)
- Version: TLS 1.2 (0x0303)
- Length: 101
- Encrypted Application Data: 1303136ee3f0e6daf0cb0e82d07fcca423c9cb2a26b29e332cdc604397f43c377df9805e…
- [Application Data Protocol: http-over-tls]
Reference
https://hpbn.co/transport-layer-security-tls/
HTTPS 權威指南
https://tls.ulfheim.net/
https://datatracker.ietf.org/doc/html/rfc5246
原文鏈接：https://mp.weixin.qq.com/s/SmX3itX8eG9MHLgEXQ_ntw
