1.  介紹

TLS 1.3 是傳輸層安全協議的最新版本，由 IETF 于 2018 年標準化（RFC 8446）。它并非 TLS 1.2 的簡單升級，而是一次徹底的重構和現代化，旨在解決其前任在安全和性能上的根本性缺陷。

1.1  發展歷程

TLS 1.3的標準化過程是一個不斷權衡安全、性能和兼容性的過程。

1.2  標準規范

RFC8446     The Transport Layer Security (TLS) Protocol Version 1.3

1.3  術語和定義

Round-Trip Time：往返時間，指一個數據包從源點發送到目的地，然后再從目的地返回一個響應包到源點所需的總時間。

客戶端（client）:  發起TLS連接的端點。

連接（connection）: 兩端之間的傳輸層連接。

端點（endpoint）:  連接的客戶端或者服務器。

握手（handshake）:  客戶端和服務器之間協商TLS交互的后續參數的出示協商。  

接收端（receiver）: 接收記錄的端點。

發送者（sender）:  發送記錄的端點。

服務器（server）:  沒有發起TLS連接的端點。

HKDF：基于HMAC的密鑰派生函數

1.4  縮略語

RTT: 往返時間(Round-Trip Time)

PSK:預共享密鑰（pre_shared_key）

2.  協議概覽

TLS1.3總共有兩層，分別是握手協議(handshake protocol)和記錄協議(record protocol)，握手協議在記錄協議的上層，記錄協議是一個分層協議。其中握手協議中還包括了警告協議(alert protocol)。

2.1  記錄協議

位于握手協議下層，發送方從高層接受任意長度的非空數據，對其進行合并或分塊處理，然后利用帶有輔助數據的認證加密AEAD（authenticated encryption with associated data）進行加密傳輸。接收方接受數據后對其進行解密和驗證，重組后再傳送給高層用戶。

2.2  警告協議

目的是以簡單的通知機制告知通信出現異常情況，警告消息通常會攜帶Close_notify異常，在連接關閉的時候報告錯誤，Alert_Level字段標識告警的嚴重程度，可取值Warning或者Fatal，嚴重程度為Fatal時會立即終止當前連接。

2.3  握手協議

安全通道使用的密碼參數由TLS握手協議生成。這個TLS的子協議在client和server第一次通信時使用。握手協議使兩端協商協議版本、選擇密碼算法、選擇性互相認證，并得到共享的密鑰數據。一旦握手完成，雙方就會使用得出的密鑰保護應用層流量。握手失敗或其它協議錯誤會觸發連接中止，在這之前可以有選擇地發送一個警報消息。

TLS1.3協議握手流程如下：

+表示在先前提到的消息中發送的值得注意的擴展

*表示可選或情境依賴的消息/擴展，不一定總是發送

{}表示使用從 [sender]_handshake_traffic_secret 導出的密鑰保護的消息

[]表示使用從 [sender]_application_traffic_secret_N 導出的密鑰保護的消息

握手可以看作有三個階段：

2.3.1  密鑰交換

選擇TLS協議版本和加密的算法，并且協商算法所需的參數。這段是明文傳輸的。

在密鑰交換階段，客戶端發送ClientHello消息，其中包含：

• 隨機的nonce（ClientHello.random)
• 所提供的協議版本
• 一組對稱密碼算法/HKDF哈希對
• Diffie-Hellman共享密鑰(在"key_share"擴展中)、預共享密鑰標簽集合(在"pre_shared_key"擴展中), 或兩者都有
• 可能的其他擴展

服務器處理ClientHello并確定適當的加密參數，然后通過ServerHello響應，指示協商的連接參數。

TLS支持3種基本的密鑰交換模式：

• 　　(EC)DHE (基于有限域或橢圓曲線的Diffie-Hellman)
•  　　PSK-only
• 　　PSK結合(EC)DHE

密鑰交換模式詳解

1)       (EC)DHE - ephemeral Diffie-Hellman

這是 TLS 1.3 的標準模式和推薦默認模式。絕大多數現代 HTTPS 連接都使用此模式。

• 原理：客戶端和服務器各自臨時生成一對臨時的 Diffie-Hellman 密鑰對（可以是基于有限域的，但更常見的是基于橢圓曲線的 ECDHE）。然后雙方交換公鑰，利用對方的公鑰和自己的私鑰，獨立計算出一個相同的共享密鑰（預主密鑰）。
• 握手特征：
• 在 ClientHello 中，客戶端在 key_share 擴展中攜帶一個或多個 (EC)DHE 公鑰。
• 在 ServerHello 中，服務器在 key_share 擴展中選定并返回它自己的 (EC)DHE 公鑰。
• 優點：
• 完美的前向安全：因為每次連接都使用臨時的密鑰對，計算出的共享密鑰僅在本次連接中有效。即使服務器長期私鑰泄露，過去的會話記錄也不會被解密。
• 廣泛支持和高性能：特別是 ECDHE，在保證高安全強度的同時，計算和通信開銷較小。
• 缺點：
• 需要完整的 1-RTT 握手。
• 應用場景：幾乎所有需要最高安全級別的場景，如網上銀行、電子郵件、社交網絡登錄等。

2)       PSK-Only

此模式完全依賴于一個雙方預先共享的密鑰來建立連接。

• 原理：客戶端和服務器在 TLS 握手開始之前，就已經通過某種安全渠道共享了一個密鑰。這個 PSK 通常來自于一次成功的完整 (EC)DHE 握手后，服務器通過 New Session Ticket 消息下發的會話票證。在恢復會話時，客戶端直接使用這個 PSK 來派生會話密鑰。
• 握手特征：
• 在 ClientHello 中，客戶端在 pre_shared_key 擴展中提供 PSK 身份標識。
• 服務器驗證 PSK 有效后，在 ServerHello 中確認使用該 PSK。
• 握手消息大幅減少，無需 Certificate 和 CertificateVerify。
• 優點：
• 極高的性能（0-RTT）：可以實現“零往返”握手，客戶端在第一次消息中就可以攜帶加密的應用數據，極大降低延遲。
• 節省計算資源：避免了昂貴的非對稱加密運算。
• 缺點：
• 不具備前向安全性：如果 PSK 被泄露，所有使用該 PSK 加密的通信（包括 0-RTT 數據）都可能被解密。
• 0-RTT 數據存在重放攻擊風險：攻擊者可以截獲客戶端發送的 0-RTT 數據并重新發送，服務器可能會多次處理該請求。
• 應用場景：
• 會話恢復：最常見的使用場景，用于快速恢復與已知服務器的連接。
• 物聯網或受限環境：設備預先配置了 PSK，無需復雜的證書管理。
• 內部微服務通信：在可控的內部網絡環境中，使用 PSK 簡化認證和提升性能。

3)       PSK with (EC)DHE

這是前兩種模式的結合，也是安全性與性能的最佳平衡點，被強烈推薦用于 PSK 模式。

• 原理：在 PSK-Only 模式的基礎上，額外增加一次 (EC)DHE 密鑰交換。最終的會話密鑰由 PSK 和 (EC)DHE 共享密鑰 共同派生。
• 握手特征：
• 在 ClientHello 中，客戶端同時提供 pre_shared_key 和 key_share 擴展。
• 服務器在 ServerHello 中確認使用 PSK，并同時返回自己的 (EC)DHE 公鑰。
• 優點：
• 保持前向安全：即使 PSK 泄露，由于每次會話都混合了新鮮的 (EC)DHE 共享密鑰，過去的會話記錄依然是安全的。
• 提供身份認證：PSK 證明了客戶端的身份（“我知道這個密鑰”），(EC)DHE 提供了新鮮度和密鑰確認。
• 緩解 0-RTT 重放攻擊：雖然不能完全消除，但結合了 DHE 的 0-RTT 模式比純 PSK 模式更難被攻擊。
• 缺點：
• 比 PSK-Only 模式多了一次 DHE 計算，但仍比完整的 (EC)DHE 握手要快。
• 應用場景：
• 需要前向安全的會話恢復：這是最理想的會話恢復方式。例如，在移動 App 與服務器的長期連接中，既要求快速恢復，又要求最高級別的安全。
• 對安全要求高的預共享密鑰場景：在任何使用 PSK 但又不愿意犧牲前向安全性的場合，都應首選此模式。

總結和對比

ClientHello和ServerHello的組合確定了共享密鑰

• 如果使用了(EC)DHE密鑰協商，則ServerHello包含服務器臨時生成DH公鑰的key_share擴展
• 如果使用PSK密鑰協商，則ServerHello包含一個pre_shared_key擴展，指示選擇了客戶端提供的PSK中的哪一個
• 請注意，實現可以同時使用(EC)DHE和PSK，在這種情況下ServerHello將提供兩個擴展。

2.3.2  服務器參數

建立其他握手協議參數，例如是否需要認證客戶端，支持何種應用層協議等。

• EncryptedExtensions：對于不需要確定密碼參數的ClientHello擴展的響應。
• CertificateRequest：如果需要客戶端身份證書驗證，則為該證書的所需參數。如果不需要客戶端身份驗證，則省略此消息

2.3.3  認證

客戶端和服務器交換身份驗證消息。具體消息如下：

Certificate：服務端證書和證書相關的擴展，如果不使用證書進行身份驗證，則服務器會省略此消息；如果使用原始公鑰或緩存的信息，則此消息將不包含證書，而是包含與服務器的長期密鑰對應的其他信息。

CertificateVerify：使用Certificate消息中公鑰對應的私鑰對整個握手消息進行簽名，如果不通過證書進行身份驗證，則省略此消息。

Finished：對應整個握手的消息認證碼MAC，此消息提供密鑰確認，將客戶端/服務端的身份與交換的密鑰綁定，并在PSK模式下還進行握手身份驗證。