HTTPS - TLS 1.3 為何性能和安全性更高？
2008 年 8 月 TLS v1.2 發布，時隔 10 年，TLS v1.3 于 2018 年 8 月發布，在性能優化和安全性上做了很大改變，同時為了避免新協議帶來的升級沖突，TLS v1.3 也做了兼容性處理，通過增加擴展協議來支持舊版本的客戶端和服務器。
安全性
TLS v1.2 支持的加密套件很多，在兼容老版本上做的很全，里面有些加密強度很弱和一些存在安全漏洞的算法很可能會被攻擊者利用，為業務帶來潛在的安全隱患。TLS v1.3 移除了這些不安全的加密算法，簡化了加密套件，對于服務端握手過程中也減少了一些選擇。
- 移除 MD5、SHA1 密碼散列函數的支持，推薦使用 SHA2(例如，SHA-256)。
- 移除 RSA 及所有靜態密鑰(密鑰協商不具有前向安全特性)。
- 溢出 RC4 流密碼、DES 對稱加密算法。
- 密鑰協商時的橢圓曲線算法增加 https://www.wanweibaike.net/wiki-X25519 支持。
- 支持帶 Poly1305消息驗證碼 的 ChaCha20 流加密算法，流加密也是一種對稱加密算法。
- 移除了 CBC 分組模式，TLS v1.3 對稱加密僅支持 AES GCM、AES CCM、ChaCha20**-**Poly1305 三種模式。
- 服務端 “Server Hello” 之后的消息都會加密傳輸，因此常規抓包分析就會有疑問為什么看不到證書信息。
性能優化
性能優化一個顯著的變化是簡化了 TLS 握手階段，由 TLS v1.2 的 2-RTT 縮短為 1-RTT，同時在第一次建立鏈接后 TLS v1.3 還引入了 0-RTT 概念。
來源 https://www.a10networks.com/wp-content/uploads/differences-between-tls-1.2-and-tls-1.3-full-handshake.png
密鑰協商在 TLS v1.2 中需要客戶端/服務端雙方交換隨機數和服務器發送完證書后，雙方各自發送 “Clent/Server Key Exchange” 消息交換密鑰協商所需參數信息。在安全性上，TLS v1.3 移除了很多不安全算法，簡化了密碼套件，現在已移除了 “Clent/Server Key Exchange” 消息，在客戶端發送 “Client Hello” 消息時在擴展協議里攜帶支持的橢圓曲線名稱、臨時公鑰、簽名信息。服務器收到消息后，在 “Server Hello” 消息中告訴客戶端選擇的密鑰協商參數，由此可少了一次消息往返(1-RTT)。
- Client Server
- Key ^ ClientHello
- Exch | + key_share*
- | + signature_algorithms*
- | + psk_key_exchange_modes*
- v + pre_shared_key* -------->
- ServerHello ^ Key
- + key_share* | Exch
- + pre_shared_key* v
- {EncryptedExtensions} ^ Server
- {CertificateRequest*} v Params
- {Certificate*} ^
- {CertificateVerify*} | Auth
- {Finished} v
- <-------- [Application Data*]
- ^ {Certificate*}
- Auth | {CertificateVerify*}
- v {Finished} -------->
- [Application Data] <-------> [Application Data]
- The basic full TLS handshake
當訪問之前訪問過的站點時，客戶端可以通過利用先前會話中的 預共享密鑰 (PSK) 將第一條消息上的數據發送到服務器，實現 “零往返時間(0-RTT)”。
- Client Server
- ClientHello
- + early_data
- + key_share*
- + psk_key_exchange_modes
- + pre_shared_key
- (Application Data*) -------->
- ServerHello
- + pre_shared_key
- + key_share*
- {EncryptedExtensions}
- + early_data*
- {Finished}
- <-------- [Application Data*]
- (EndOfEarlyData)
- {Finished} -------->
- [Application Data] <-------> [Application Data]
- Message Flow for a 0-RTT Handshake
TLS v1.3 抓包分析
以一次客戶端/服務端完整的 TLS 握手為例，通過抓包分析看下 TLS v1.3 的握手過程。下圖是抓取的 www.zhihu.com 網站數據報文，且對報文做了解密處理，否則 “Change Cipher Spec” 報文后的數據都已經被加密是分析不了的。抓包請參考 “網絡協議那些事兒 - 如何抓包并破解 HTTPS 加密數據?”。
image.png
TLS v1.3 握手過程如下圖所示：
tls-1-3-full-handshake.jpg
Client Hello
握手開始客戶端告訴服務端自己的 Random、Session ID、加密套件等。
除此之外，TLS v1.3 需要關注下 “擴展協議”，TLS v1.3 通過擴展協議做到了 “向前兼容“，客戶端請求的時候告訴服務器它支持的協議、及一些其它擴展協議參數，如果老版本不識別就忽略。
下面看幾個主要的擴展協議：
- supported_versions：客戶端支持的 TLS 版本，供服務器收到后選擇。
- supported_groups：支持的橢圓曲線名稱
- key_share：橢圓曲線名稱和對應的臨時公鑰信息。
- signature_algorithms：簽名
- Transport Layer Security
- TLSv1.3 Record Layer: Handshake Protocol: Client Hello
- Version: TLS 1.0 (0x0301)
- Handshake Protocol: Client Hello
- Handshake Type: Client Hello (1)
- Version: TLS 1.2 (0x0303)
- Random: 77f485a55b836cbaf4328ea270082cdf35fd8132aa7487eae19997c8939a292a
- Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
- Cipher Suites (16 suites)
- Cipher Suite: Reserved (GREASE) (0x1a1a)
- Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
- Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
- Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
- Extension: signature_algorithms (len=18)
- Extension: supported_groups (len=10)
- Supported Groups (4 groups)
- Supported Group: Reserved (GREASE) (0xcaca)
- Supported Group: x25519 (0x001d)
- Supported Group: secp256r1 (0x0017)
- Supported Group: secp384r1 (0x0018)
- Extension: key_share (len=43)
- Type: key_share (51)
- Key Share extension
- Client Key Share Length: 41
- Key Share Entry: Group: Reserved (GREASE), Key Exchange length: 1
- Key Share Entry: Group: x25519, Key Exchange length: 32
- Group: x25519 (29)
- Key Exchange Length: 32
- Key Exchange: 51afc57ca38df354f6d4389629e222ca2654d88f2800cc84f8cb74eefd473f4b
- Extension: supported_versions (len=11)
- Type: supported_versions (43)
- Supported Versions length: 10
- Supported Version: TLS 1.3 (0x0304)
- Supported Version: TLS 1.2 (0x0303)
Server Hello
服務端收到客戶端請求后，返回選定的密碼套件、Server Random、選定的橢圓曲線名稱及對應的公鑰(Server Params)、支持的 TLS 版本。
這次的密碼套件看著短了很多 TLS_AES_256_GCM_SHA384，其中用于協商密鑰的參數是放在 key_share 這個擴展協議里的。
- TLSv1.3 Record Layer: Handshake Protocol: Server Hello
- Content Type: Handshake (22)
- Handshake Protocol: Server Hello
- Handshake Type: Server Hello (2)
- Version: TLS 1.2 (0x0303)
- Random: 1f354a11aea2109ba22e26d663a70bddd78a87a79fed85be2d03d5fc9deb59a5
- Session ID: 8d4609d9f0785880eb9443eff3867a63c23fb2e23fdf80d225c1a5a25a900eee
- Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
- Compression Method: null (0)
- Extensions Length: 46
- Extension: supported_versions (len=2)
- Supported Version: TLS 1.3 (0x0304)
- Extension: key_share (len=36)
- Type: key_share (51)
- Key Share extension
- Key Share Entry: Group: x25519, Key Exchange length: 32
- Group: x25519 (29)
- Key Exchange: ac1e7f0dd5a4ee40fd088a8c00113178bafb2df59e0d6fc74ce77452732bc44d
服務端此時拿到了 Client Random、Client Params、Server Random、Server Params 四個參數，可優先計算出預主密鑰。在 TLS v1.2 中是經歷完第一次消息往返之后，客戶端優先發起請求。
在計算出用于對稱加密的會話密鑰后，服務端發出 Change Cipher Spec 消息并切換到加密模式，之后的所有消息(證書、證書驗證)傳輸都會加密處理，也減少了握手期間的明文傳遞。
Certificate、Certificate Verify、Finished
除了 Certificate 外，TLS v1.3 還多了個 “Certificate Verify” 消息，使用服務器私鑰對握手信息做了一個簽名，強化了安全措施。
- Transport Layer Security
- TLSv1.3 Record Layer: Handshake Protocol: Certificate
- TLSv1.3 Record Layer: Handshake Protocol: Certificate Verify
- Handshake Protocol: Certificate Verify
- Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
- Signature Hash Algorithm Hash: Unknown (8)
- Signature Hash Algorithm Signature: Unknown (4)
- Signature length: 256
- Signature: 03208990ec0d4bde4af8e2356ae7e86a045137afa5262ec7c82d55e95ba23b6eb5876ebb…
- TLSv1.3 Record Layer: Handshake Protocol: Finished
- Handshake Protocol: Finished
- Verify Data
客戶端切換加密模式
客戶端獲取到 Client Random、Client Params、Server Random、Server Params 四個參數計算出最終會話密鑰后，也會發起 “Certificate Verify”、“Finished” 消息，當客戶端和服務端都發完 “Finished” 消息后握手也就完成了，接下來就可安全的傳輸數據了。
image.png
