TLS 1.3的0-RTT模式有什么安全风险？
TLS 1.3 的 0-RTT（零往返时间）模式虽然能显著降低首包延迟，实现“零延迟”传输，但这种“快”是以牺牲部分安全属性为代价的。它主要存在以下三大核心安全风险：
- 重放攻击（Replay Attack）风险
这是 0-RTT 面临的最大安全威胁。在 0-RTT 连接建立中，客户端在服务器提供新的随机数（nonce）之前就已经发送了数据。攻击者如果截获了客户端的有效 0-RTT 消息，可以在票证有效期内原样重复发送给服务器。如果服务器未加拦截，可能会将重放消息当作新请求处理，导致重复扣款、虚假订单提交、账号被反复尝试暴力登录等严重后果。 - 前向保密性（Forward Secrecy）失效
0-RTT 机制基于预共享密钥（PSK）。由于客户端和服务器没有建立完整的握手过程，共享的恢复主密钥不会受益于前向保密特性。这意味着，如果服务端的 PSK 密钥发生泄露，攻击者就可以解密所有历史 0-RTT 流量。 - 缺乏双向认证
在 0-RTT 阶段，服务器不会验证客户端的身份，它仅依赖于首次完整握手建立的信任。这使得攻击者更容易利用截获的数据包伪造合法请求。
💡 缓解与防御建议：
0-RTT 本身并非本质上不安全，但它需要应用层与网络层的协同防御：
限制请求方法：0-RTT 仅适用于幂等（Idempotent）或其他安全的请求（如 GET、HEAD 等纯读取操作）。对于包含状态更改的敏感操作（如 POST、PUT、DELETE、支付、登录等），必须拒绝 0-RTT 或强制客户端降级为 1-RTT 重发。
实施防重放机制：后端应用必须承担防御动作。收到早期数据后，需引入一次性随机数（Nonces）去重、精确的时间戳窗口校验（如限制在 5 秒内），以及请求指纹（Body Hash + Client IP + UA 哈希）等应用层防护手段。
Nginx 协同配置：Nginx 作为第一道防线，需在 TLS 解密后通过透传 Early-Data 头（如 proxy_set_header Early-Data $ssl_early_data;）明确告知后端该请求是否为 0-RTT，以便后端执行针对性的拦截和校验逻辑。