2017年2月，一篇发表在IACR密码学预印本上的论文提出了一个尖锐的问题：当一个协议试图在零次往返中建立安全连接时，它是否还能保持密码学的安全承诺？这篇由德国达姆施塔特工业大学Marc Fischlin和Felix Günther撰写的论文，标题本身就揭示了问题的核心——《Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates》。
论文的结论令人不安：TLS 1.3的0-RTT模式在设计上就接受了一个事实——早期数据可以被重放。这不是实现缺陷，而是协议设计者权衡性能与安全后的主动选择。
七年后的今天，HTTP/3已经获得超过95%的主流浏览器支持，成为互联网的新基石。然而，0-RTT的安全隐患却如同幽灵般潜伏在这个"更快、更安全"的协议之中。理解这个问题，需要深入TLS 1.3与QUIC的设计内核。
速度的诱惑：零往返的技术逻辑
传统的HTTPS连接建立需要经历一个繁琐的握手过程。以TLS 1.2为例，客户端首先发起TCP三次握手，然后进行TLS握手——ClientHello、ServerHello、证书交换、密钥协商——整个流程需要2-3个往返时延（RTT）。对于一个从北京访问纽约服务器的用户，单程延迟约200毫秒，完整握手可能消耗近一秒。
TLS 1.3将这个流程压缩到了1-RTT，通过合并加密和认证握手步骤实现了显著优化。但对于那些用户频繁访问的网站，设计者希望做得更好：如果客户端之前已经与服务器建立过连接，能否跳过所有协商，直接发送应用数据？
这正是0-RTT（Zero Round-Trip Time）的设计初衷。其核心机制是"预共享密钥"（Pre-Shared Key, PSK）：在首次连接结束时，服务器向客户端颁发一个会话票据（Session Ticket）。客户端在后续连接中可以使用这个票据，连同加密的应用数据一起，在第一个数据包中发送给服务器。
从架构图上看，这个流程简洁得令人惊叹：
客户端 服务器
ClientHello
(0-RTT应用数据) -------->
ServerHello
{EncryptedExtensions}
{Finished}
<-------- [应用数据]
{Finished} -------->
[应用数据] <-------> [应用数据]
客户端无需等待服务器的任何响应，就能发送加密的HTTP请求。对于移动网络环境，这可能节省数百毫秒的延迟。Cloudflare的实测数据显示，启用0-RTT后，页面首次访问的感知延迟可降低30%以上。
然而，天下没有免费的午餐。这个优雅的设计背后，隐藏着一个根本性的密码学困境。
密码学的阿喀琉斯之踵：前向保密的丧失
要理解0-RTT的安全问题，首先需要理解现代密码学的一个核心概念：前向保密（Forward Secrecy）。
前向保密的含义是：即使攻击者在未来某个时刻获取了服务器的长期私钥，也无法解密过去截获的通信内容。TLS 1.3通过每次连接都生成临时的Diffie-Hellman密钥交换来实现这一目标。每条连接使用独立的临时密钥，连接结束后即销毁，攻击者即使日后攻破服务器，也无法回溯解密历史流量。
但0-RTT打破了这个安全边界。
当客户端使用会话票据发送0-RTT数据时，它使用的是从之前连接中派生的密钥。这意味着：
第一，这些密钥不具备前向保密性。如果攻击者在票据有效期内攻破了服务器的会话密钥存储，所有使用该票据建立的0-RTT连接都将暴露。
第二，更致命的是，服务器没有对0-RTT数据做出任何贡献。在正常的TLS握手（即使是1-RTT模式）中，服务器通过发送ServerHello和自己的随机数，参与了会话密钥的生成。这确保了每条连接的密钥都是唯一的。但在0-RTT模式中，客户端独自生成了加密密钥——服务器在这一轮中完全是被动的。
正是这种不对称性，为重放攻击打开了大门。
重放攻击：理论威胁与现实风险
RFC 8446（TLS 1.3规范）的附录E.5明确指出：“TLS不为0-RTT数据提供固有的重放保护”。
这是一个刻意的设计选择，而非疏忽。规范继续写道：“攻击者可能捕获并重放其中包含的请求。TLS描述了一些可以减少攻击者成功重放请求可能性的技术，但这些技术可能难以部署，并且仍然存在成功攻击的可能性。”
攻击机制的技术细节
重放攻击的核心逻辑出奇地简单：
- 攻击者处于客户端与服务器之间的网络路径上（例如恶意WiFi热点、被入侵的路由器）
- 客户端发起0-RTT连接，发送加密的早期数据
- 攻击者复制这个数据包
- 攻击者将数据包重新发送给服务器（可能多次）
- 服务器处理每一个副本，执行相应的操作
需要强调的是，攻击者无法解密或篡改这些数据——TLS的加密和完整性保护仍然有效。但攻击者不需要理解数据内容，只需要重复发送即可。
一个典型的攻击场景：用户通过移动银行应用发起转账请求，恰好使用了0-RTT连接。攻击者截获这个请求并重放十次。如果服务器没有正确处理，用户的账户可能被扣除十倍的金额。
这听起来像是极端案例，但现实远比想象中复杂。
幂等性的迷思
HTTP协议长期以来有一个约定：GET请求应该是"幂等"（idempotent）的，即多次执行同一请求不应产生不同的副作用。这成为了一些开发者认为0-RTT安全的理论基础。
但这个假设存在致命缺陷：
第一，幂等性并非强制约束。HTTP规范用词是"SHOULD"，而非"MUST"。实际应用中，大量API使用GET请求执行查询操作，而这些操作可能触发服务器端的日志记录、统计更新、限流计数等副作用。
第二，即使请求本身幂等，重放仍可能造成危害。Fischlin和Günther在论文中详细分析了这个问题：大量重放可能导致资源耗尽、统计失真、或触发其他安全机制。
第三，GET请求的查询参数可能编码敏感操作。一个设计不当的API可能使用GET /api/transfer?from=A&to=B&amount=100这样的URL模式，完全违背了幂等性假设。
2017年，Daniel Kahn Gillmor在TLS工作组邮件列表中提出了一个更具破坏性的攻击场景：即使服务器端实现了防重放机制，攻击者仍可能利用协议层面的"自动重试"行为绕过防御。
攻击流程如下：
客户端 攻击者 服务器
| | |
|--- ClientHello -------->| |
| + 0-RTT 数据 | |
| |--- ClientHello -------->| 处理数据
| | + 0-RTT 数据 | (第一次)
| | |
| |<-- ServerHello ---------| 拒绝0-RTT
| | (服务器状态丢失) |
| | |
| |--- ClientHello -------> | 重新处理
| | (攻击者丢弃响应) | (第二次)
| | |
|<-- ServerHello ---------|<-- ServerHello ---------|
| | |
|--- 数据重发 ----------->|--- 数据重发 ----------->| 处理数据
| (客户端自动重试) | | (第三次)
这个攻击的关键在于：服务器集群的不同实例可能对0-RTT数据做出不同的处理决策。当客户端的自动重试机制与服务器的不一致状态相遇时，同一条请求可能被处理多次——而客户端和服务器的开发者都认为自己在正确实现协议。
规范的应对：RFC 8470与HTTP层的补救
面对这个根本性的协议设计困境，IETF并没有坐视不管。2018年9月，RFC 8470正式发布，标题为《Using Early Data in HTTP》。
这份规范的核心贡献是定义了一套HTTP层的信号机制，帮助客户端和服务器协调0-RTT数据的使用：
Early-Data请求头
当请求可能在握手完成前被转发时，中介（如反向代理、CDN）必须添加Early-Data: 1请求头。这允许源服务器识别请求的来源状态。
GET /resource HTTP/1.1
Host: example.com
Early-Data: 1
425 (Too Early)状态码
这是RFC 8470最重要的贡献。当服务器认为处理某个早期数据请求的风险过高时，它可以返回425状态码，要求客户端在完成完整握手后重试：
HTTP/1.1 425 Too Early
RFC 8476对425状态码的定义是：“服务器不愿冒险处理可能被重放的请求。”
这是一个优雅的解决方案：它不试图在TLS层面解决重放问题（这是不可能的），而是在应用层提供了明确的拒绝和重试机制。客户端收到425后，必须等待握手完成，然后使用普通的1-RTT密钥重新发送请求。
客户端的保守策略
RFC 8470对客户端也提出了明确要求：
“客户端可以发送具有安全HTTP方法的请求…但不得发送不安全方法（或安全性未知的方法）在早期数据中。”
安全方法包括GET、HEAD、OPTIONS和TRACE；不安全方法包括POST、PUT、DELETE等。这个区分基于HTTP语义：安全方法不应产生服务器端副作用。
业界的实践：从Cloudflare到各大厂商
理论规范是一回事，实际部署是另一回事。作为全球最大的CDN提供商之一，Cloudflare对0-RTT的处理策略具有代表性。
Cloudflare的保守策略
Cloudflare在2017年首次支持TLS 1.3 0-RTT，但采取了极度谨慎的策略：
第一，仅允许无查询参数的GET请求。任何带有查询字符串的GET请求都会被拒绝，以防止类似GET /api/action?param=value这样的模式。
第二，拒绝POST和PUT请求。这是基于HTTP规范的直接应用。
第三，添加唯一标识头。Cloudflare会在0-RTT请求中添加CF-0RTT-Unique头，其值从PSK binder派生。源服务器可以跟踪这些值，拒绝重复请求。
然而，这个策略仍然存在盲点。正如Trail of Bits的安全研究团队指出的：如果一个API设计不当，使用GET请求执行非幂等操作（这在遗留系统中并不罕见），Cloudflare的策略无法阻止重放攻击。
其他厂商的响应
值得注意的是，Go语言的TLS实现至今不支持0-RTT。Russ Cox在相关讨论中表示，主要担忧正是如何安全地暴露这一功能给应用层。
Nginx从1.25.0版本开始支持ssl_early_data指令，但默认禁用。官方文档明确警告：“启用早期数据会暴露于重放攻击。只有当你确定后端应用能正确处理早期数据请求时，才应启用此选项。”
HAProxy提供了更细粒度的控制：通过allow-0rtt指令启用后，会自动添加Early-Data请求头，并支持源服务器返回425状态码时自动重试。
开发者的实践指南
面对0-RTT的安全挑战，应用开发者应该采取什么策略？基于官方规范和业界最佳实践，可以总结出以下原则：
原则一：默认禁用，显式启用
如果使用Nginx、HAProxy等反向代理，确保0-RTT功能处于禁用状态。只有在完成安全评估后，才考虑启用。
# 默认配置：禁用0-RTT
# ssl_early_data off;
# 如果确定要启用，必须在应用层做好防护
# ssl_early_data on;
原则二：识别Early-Data请求
应用服务器必须能够识别哪些请求来自0-RTT阶段。这意味着：
- 检查
Early-Data: 1请求头 - 检查特定CDN添加的标识头（如
CF-0RTT-Unique）
原则三：对早期数据请求返回425
对于任何可能产生不可逆副作用的操作，如果请求带有早期数据标识，应该返回425状态码：
def handle_request(request):
if request.headers.get('Early-Data') == '1':
if request.method in ['POST', 'PUT', 'DELETE', 'PATCH']:
return Response(status=425)
if has_side_effects(request):
return Response(status=425)
# 正常处理逻辑
原则四：实现应用层幂等性保护
对于必须支持0-RTT的API，实现自己的幂等性保护机制：
- 使用请求ID（Request ID）或幂等令牌
- 在服务器端维护已处理请求的短期缓存
- 检测并拒绝重复的请求ID
// 客户端发送带有唯一ID的请求
fetch('/api/transfer', {
method: 'POST',
headers: {
'Idempotency-Key': generateUUID(),
'Content-Type': 'application/json'
},
body: JSON.stringify({to: 'recipient', amount: 100})
});
// 服务器端检测重复
if (await cache.exists(request.headers['Idempotency-Key'])) {
return previous_response; // 返回之前的结果
}
原则五：审计现有API设计
检查现有系统中是否存在使用GET请求执行非幂等操作的情况。如果有，进行重构或至少在API网关层面拒绝这些请求的0-RTT访问。
技术的边界：当性能与安全无法兼得
0-RTT的设计困境揭示了一个更深层的问题：在网络协议的设计中，性能优化与安全保证之间存在难以调和的张力。
TLS 1.3的设计者们做出了理性的选择：他们没有试图用复杂的技术方案去"解决"重放问题（这可能导致更脆弱的系统），而是诚实地承认了0-RTT的局限性，并通过规范引导开发者正确使用。
RFC 8446附录E.5中的一段话值得全文引用：
“使用早期数据的风险在于攻击者可能捕获并重放其中包含的请求。可以减少成功重放可能性的机制包括：在服务器的单一实例中记录ClientHello值并拒绝重复…在多个服务器之间共享状态…或使用其他技术限制重放…在许多情况下，在TLS层实现这些技术可能不切实际。”
这段话的潜台词是：如果你无法在应用层正确处理重放风险，就不要启用0-RTT。
2024年，HTTP/3的支持率已超过95%。对于绝大多数只传输静态资源的网站来说，0-RTT带来的性能提升是真实的，安全风险也是可控的。但对于涉及金融交易、状态变更、敏感操作的API，开发者必须保持警惕。
速度的诱惑永远存在。但在安全领域，最危险的不是已知的漏洞，而是对风险的系统性低估。0-RTT不是"bug"，它是协议设计者在清醒权衡后做出的trade-off——而这个trade-off的代价，需要每一位开发者在自己的应用场景中认真评估。
参考资料
- RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
- RFC 8470: Using Early Data in HTTP
- RFC 9001: Using TLS to Secure QUIC
- RFC 9114: HTTP/3
- Fischlin, M. & Günther, F. (2017). Replay Attacks on Zero Round-Trip Time: The Case of the TLS 1.3 Handshake Candidates. IACR Cryptology ePrint Archive 2017/082.
- Cao, Y. et al. (2019). 0-RTT Attack and Defense of QUIC Protocol.
- Lychev, R. et al. (2015). How Secure is QUIC? USENIX Security Symposium.
- Cloudflare Blog: Even faster connection establishment with QUIC 0-RTT resumption (2019)
- Trail of Bits: What Application Developers Need To Know About TLS Early Data (2019)
- ETH Zürich: A Survey of TLS 1.3 0-RTT Usage (2021)
- IEEE EuroS&P 2017: Replay Attacks on Zero Round-Trip Time