【网络工程】TLS 1.3 工程实践：1-RTT 与 0-RTT 的安全权衡
内容提要
TLS 1.3于2018年发布，将完整握手从2 RTT压缩至1 RTT，并引入0-RTT恢复模式。它移除了RSA密钥交换、CBC模式等不安全特性，仅保留5种AEAD密码套件。密钥推导改用HKDF，支持KeyUpdate密钥轮换。0-RTT虽能首包发送数据，但存在重放风险，仅建议用于幂等操作。部署时需应对中间设备僵化问题，升级路径可渐进式兼容TLS 1.2。
延伸解读
0-RTT 重放风险的实际影响
0-RTT 虽然能显著降低延迟，但其重放风险是实际部署中必须正视的问题。文章明确指出，0-RTT 数据在服务器响应前就已发送，无法依赖服务器随机数防重放，因此仅适用于幂等操作。对于非幂等请求（如转账、下单），必须禁用 0-RTT 或在应用层实现幂等保护。服务器端可结合时间窗口、一次性票据等策略缓解风险，但最可靠的仍是应用层防护。
中间设备僵化：部署的最大障碍
TLS 1.3 为兼容老旧中间设备，不得不伪装成 TLS 1.2 进行版本协商，并发送假的 ChangeCipherSpec 消息。这反映出协议演进不仅取决于自身设计，还受制于网络基础设施的更新速度。企业在升级 TLS 1.3 时，需提前检查防火墙、IDS 等设备是否支持，否则可能遭遇握手超时或连接中断。渐进式升级（同时启用 TLS 1.2 和 1.3）是降低风险的常见策略。
密码套件选择与硬件加速
TLS 1.3 仅保留 5 种 AEAD 密码套件，但不同套件在不同硬件上的性能差异显著。文章指出，支持 AES-NI 的服务器优先选择 AES-128-GCM 可获得最佳性能；而移动设备或嵌入式设备（无 AES-NI）则更适合 ChaCha20-Poly1305，其速度可快 3 倍以上。因此，服务器应允许客户端优先选择密码套件（ssl_prefer_server_ciphers off），以适配多样化的客户端环境。
Q&A
TLS 1.3 相比 TLS 1.2 在握手延迟上有什么改进？
TLS 1.3 将完整握手从 2 RTT 压缩到 1 RTT，并引入了 0-RTT 恢复模式，允许客户端在第一个包中发送加密数据，从而显著降低连接建立延迟。
TLS 1.3 移除了哪些不安全的加密特性？
TLS 1.3 移除了 RSA 密钥交换、CBC 模式加密、RC4、3DES、压缩、重新协商、静态 RSA/DH、MD5/SHA-1 签名、DSA 签名和自定义 DHE 参数，以减少攻击面。
TLS 1.3 保留了哪些密码套件？
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。
TLS 1.3 的 0-RTT 模式有什么安全风险？
0-RTT 模式的主要安全风险是重放攻击，因为客户端在收到服务器响应前就发送了数据，服务器无法提供一次性随机数来防止重放。因此，0-RTT 仅建议用于幂等操作，如 GET 请求。
TLS 1.3 中密钥推导使用了什么算法？
TLS 1.3 使用 HKDF（RFC 5869）进行密钥推导，分为 Extract 和 Expand 两步，并采用三级密钥调度（Early Secret、Handshake Secret、Master Secret）。
TLS 1.3 如何解决中间设备僵化问题？
TLS 1.3 通过伪装版本号（在 ClientHello 和 ServerHello 中保持 TLS 1.2 的版本字段，实际版本在 supported_versions 扩展中协商）以及发送假的 ChangeCipherSpec 消息来兼容中间设备，避免因不识别新协议而丢包。
TLS 1.3 的 KeyUpdate 机制有什么作用？
KeyUpdate 允许在长连接中无需重新握手即可更新应用数据的加密密钥，适用于 HTTP/2 等长时间复用连接，提高了安全性。
如何从 TLS 1.2 升级到 TLS 1.3？
升级路径包括：检查 OpenSSL 版本（需 1.1.1+）、测试 TLS 1.3 支持、确保密码套件兼容、更新证书签名算法（避免 SHA-1），并在 Nginx 等服务器上同时启用 TLS 1.2 和 1.3 进行渐进式过渡。
