TLS 1.3：0-RTT、早期数据与会话恢复

TLS 1.3（RFC 8446，2018 年）重新设计了 TLS 握手，以降低延迟并移除历史遗留包袱。完整的 TLS 1.3 握手只需 1-RTT：客户端在第一轮消息中发送带有受支持 key_shares（临时 ECDH 公钥）的 ClientHello；服务器返回 ServerHello、其 key_share、加密扩展、证书和 Finished——全部在一次响应中完成。客户端发送 Finished 后即可立即发送应用数据。与 TLS 1.2 的 2-RTT 握手相比，这使新会话的连接建立时间缩短了一半。

TLS 1.3 使用 HKDF（基于 HMAC 的密钥派生函数）和结构化的密钥调度。在 ECDHE 密钥交换之后，共享密钥会输入一个分层结构：Extract(early_secret, DHE) -> handshake_secret；随后 Extract(handshake_secret, 0) -> master_secret。HKDF-Expand-Label 再基于这些密钥分别派生客户端和服务器的握手流量密钥、应用流量密钥以及会话恢复密钥。这种清晰的分离确保某一层密钥遭到泄露不会影响其他层，这是对 TLS 1.2 中更为临时拼凑的基于 PRF 的密钥派生方式的重大改进。

TLS 1.3 的会话恢复使用从先前会话派生的预共享密钥（PSK）。握手完成后，服务器会发送 NewSessionTicket 消息，其中包含 PSK 身份和票据值（保存会话恢复密钥的加密数据块）。重新连接时，客户端会在 ClientHello 中加入 PSK 身份。如果服务器识别出该身份，双方会使用 PSK 加上新的 ECDHE 派生新的会话密钥，从而在保持前向保密性的同时实现 1-RTT 会话恢复。票据具有可配置的生命周期（通常为 24 小时），并且应使用服务器端轮换的密钥进行加密。

TLS 1.3 允许恢复的会话发送 0-RTT 早期数据。客户端使用先前会话中的 PSK 加密应用数据，并在第一轮消息中发送这些数据——此时服务器尚未发送任何确认。这为连接到之前访问过的服务器省去了一次往返，从而让重复连接几乎可以实现零延迟。服务器通过 NewSessionTicket 中的 early_data 扩展和 max_early_data_size 宣布支持 0-RTT。服务器必须具备接受或拒绝 0-RTT 数据的机制，并在 EncryptedExtensions 中表明是否接受。

0-RTT 数据存在一项根本性的安全限制：它容易受到重放攻击。截获第一轮消息的路径上的攻击者可以将其重放给服务器，使服务器再次处理早期数据。这是该机制固有的问题——服务器尚未发送任何消息，因此不存在由服务器提供的新鲜性。缓解措施包括：(1) 一次性票据（服务器使用 memcached/Redis 等分布式缓存，在票据首次使用后将其作废）；(2) 时间限制票据（在较短时间窗口后拒绝 0-RTT，例如 5 秒）；(3) 应用层幂等性（仅允许 0-RTT 用于安全的、与 GET 等价的操作）。

最可靠的 0-RTT 反重放机制是使用一次性会话票据。服务器会维护一个“已使用票据”存储区（在多服务器部署中，该存储区是分布式缓存）。收到 0-RTT 数据时，服务器会检查之前是否见过该票据——如果见过，就拒绝早期数据并回退到 1-RTT；如果没有，就将票目标记为已使用并处理早期数据。为确保正确性，集群中的所有服务器都必须共享已使用票据缓存。具有较短 TTL 的 Redis（与票据生命周期相匹配）是一种常见实现。没有这一机制时，0-RTT 对支付等非幂等操作来说并不安全。

不使用 DHE 的 TLS 1.3 PSK 会话恢复无法为恢复的会话提供前向保密性——如果 PSK 日后遭到泄露，所有恢复会话的流量都可能被解密。为保持前向保密性，TLS 1.3 支持 PSK-with-DHE：ClientHello 同时包含 PSK 身份和新的 key_share。服务器结合 PSK 与 ECDHE 输出，派生会话密钥。即使 PSK 遭到泄露，ECDHE 提供的密钥材料仍能确保过去的流量受到保护。RFC 8446 建议，在所有需要前向保密性的会话恢复场景中使用 PSK-with-DHE。

TLS 1.2 拥有 300 多种密码套件组合，其中许多并不安全。TLS 1.3 将其减少为 5 种密码套件，全部使用 AEAD：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_AES_128_CCM_SHA256 和 TLS_AES_128_CCM_8_SHA256。密钥交换和身份验证通过 supported_groups 与 signature_algorithms 扩展分别协商。这种分离消除了 TLS 1.2 的组合复杂性，并确保每个 TLS 1.3 连接都使用认证加密。

实际上，0-RTT 最适用于 HTTP/2 连接：客户端向之前访问过的服务器重复发送 GET 请求，而该请求既安全又具备幂等性。浏览器会谨慎实现 0-RTT：Chrome 会为安全的 HTTP 方法启用它，但绝不会将 POST 请求作为 0-RTT 数据发送。基于 QUIC 的 HTTP/3 原生集成了 TLS 1.3，QUIC 的 0-RTT 复用了 TLS 1.3 的机制。在 QUIC 中，0-RTT 还会从之前的会话恢复传输参数（流量控制、流限制），因此不仅能降低 TLS 层的开销，还能进一步减少连接建立开销。

TLS 1.3 包含防止版本降级攻击的机制。协商 TLS 1.3 时，ServerHello 的随机数字段会包含一个哨兵值：在回退到 TLS 1.2 时，最后 8 个字节会设置为固定值（0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01）。支持 TLS 1.3 的客户端在服务器协商 TLS 1.2 时会检查此哨兵值，从而检测主动降级尝试。此外，Finished 转录哈希会覆盖整个握手过程，包括版本协商，因此可以检测出任何篡改。SCSV（信令密码套件值），例如 TLS_FALLBACK_SCSV，则为较旧的 TLS 版本提供独立的降级信号。

部署 TLS 1.3 需要关注多个运维细节。会话票据加密密钥必须轮换（通常每 24 小时一次），并在服务器集群之间同步，以便恢复请求可以发送到任意服务器。旧的票据解密密钥必须保留到票据生命周期结束，否则可能导致无端的握手失败。OCSP 装订在 TLS 1.3 中更加重要，因为检查证书状态时少了一次往返。负载均衡器必须不经修改地传递 TLS 1.3 ClientHello——一些较旧的中间盒会破坏未知扩展，因此需要启用兼容模式。

为什么 TLS 1.3 中的 0-RTT 早期数据容易受到重放攻击？

TLS 1.3 通过 PSK 会话票据实现 1-RTT 完整握手和 0-RTT 会话恢复。密钥派生使用 HKDF 和结构化调度，为每个流量层生成独立密钥。0-RTT 早期数据省去了一次往返，但容易受到重放攻击；可以通过一次性票据以及将 0-RTT 限制在幂等操作中来缓解。PSK-with-DHE 能在会话恢复中保持前向保密性。TLS 1.3 将密码套件限制为 5 种 AEAD 选项，消除了不安全的历史组合。降级防护使用服务器随机数字段中的哨兵值。