摘要

  • TLS 1.3 的 0-RTT 可以降低恢复连接的时延，却不会天然阻止攻击者重放已经被接受的早期数据。
  • 可辩护的控制必须把传输接受事件与请求语义、应用幂等、当前授权以及实际提交的副作用连接起来。

设想一个支付服务允许熟悉的客户端恢复 TLS 会话，并把转账命令放在早期数据中发送。一个边缘节点在新握手完成前解密并转发了请求；同一票据的接受窗口内，一份重放副本抵达另一个边缘节点。两个节点都记录了“有效早期数据”，账本却收到两条命令。传输层履行了自己的承诺，应用层却把它误解成了另一种承诺。

省下一个往返，边界并没有消失

RFC 8446 允许使用预共享密钥恢复连接的客户端，在新握手完成前发送 0-RTT 应用数据。对时延敏感的读取，以及重复执行不会改变结果的操作，这项能力可以显著改善首次响应。

安全边界写得很清楚：TLS 不为 0-RTT 数据提供固有的重放保护。记录了早期报文的攻击者可以重放 ClientHello 及其关联数据。服务器仍可能正确认证恢复上下文并解密字节。因此，密码学上的“接受”只证明数据符合一个被允许的早期数据上下文，不能证明它只被投递一次，更不能证明业务动作只执行一次。

监控面板很容易遮住这条边界。票据有效、0-RTT 被接受、应用返回成功，都可能显示为绿色；这些字段没有说明相同命令是否到达了另一个进程、区域或重试路径。一个成功的 TLS 事件，比“业务效果恰好发生一次”窄得多。

防重放是一套运行系统，不是一个开关

RFC 8446 描述了若干降低风险的办法，包括一次性票据、记录 ClientHello，以及根据票据年龄和观测到达时间进行新鲜度检查。每种方法都会产生实际的运行依赖。一次性票据要求接受状态不能丢失，也不能在多个节点之间分叉；ClientHello 记录需要一个容量有界且持续可用的重放数据库；新鲜度检查则依赖时钟、容差和对剩余风险窗口的明确选择。

到了分布式边缘，局部判断不再等于全局证明。如果两个站点可以接受同一恢复材料，却不共享一次性使用决策，那么一个节点的“此前未见”并不能证明整个服务都未见过。如果故障切换策略允许在重放状态不可用时继续接受，可靠性政策实际上扩大了执行面。这可能是合理取舍，但不能被“0-RTT 已接受”这个标签隐藏。

拒绝早期数据也不会免除应用责任。客户端可能在握手后重试。如果第一次请求在拒绝结果传回前已经越过应用边界，自动重试仍可能制造第二个副作用。证据必须贯穿接受、拒绝、转发、重试和最终提交，而不能停在 TLS 记录上。

HTTP 把缺失的应用决策暴露出来

RFC 8470 规定 HTTP 如何使用早期数据，并区分客户端、中间节点和源站的责任。客户端不应随意把不安全操作放入早期数据；中间节点需要保留“请求来自早期数据”的信号；不愿承担处理风险的服务器可以返回 425 Too Early，让客户端在握手完成后重新发送。

这个状态码是一次控制权交接，不是说凡被接受的请求都无害。仅靠 HTTP 方法名也不足以分类：表面安全的读取可能产生计费、消耗稀缺名额或写入审计记录；名义上幂等的写操作，如果缺少应用键，或各区域采用不同作用域，也会失去幂等性。重放安全属于当前状态下实际实现的操作语义。

QUIC 让同一边界变成现实的执行路径。RFC 9001 把 TLS 早期数据用于 QUIC；服务器可以拒绝 0-RTT，客户端必须处理该结果。由此产生的再次发送，是应用执行图的一部分。只统计被接受的 QUIC 数据包，无法证明业务命令只被应用一次。

建立早期数据决策收据

长期可用的证据对象应是一份早期数据决策收据。它应连接恢复票据指纹与年龄、ClientHello 或握手引用、接受节点、防重放机制及窗口、请求指纹、方法和副作用类别、应用幂等键、主体与授权策略版本、转发结果、重试历史、已提交效果和决策时间。

收据还必须保存不确定性。单节点观测不能证明全服务唯一；有效票据不能证明当前业务权限；如果隐藏请求头、账户状态或区域作用域发生变化，同一请求哈希也不必然代表同一语义；传输层拒绝更不能证明下游没有观察或处理第一次尝试。

把这些判断分开，性能选择才可治理。团队可以对重复无害的操作开放 0-RTT，对有限的写操作要求全局执行的幂等键，也可以在授权和不可逆副作用无法安全判断时拒绝早期数据。真正有价值的指标，不是加速了多少次握手，而是多少早期数据操作仍保有可解释的执行历史。

来源