本文主要探讨TLS协议，看看它如何允许客户机开始发送HTTP要求，并且无需等待TLS握手完成即可减少延迟、建立更快的连接。此外，之中会有一些风险如通过API端点发送HTTP请求间的bank API重放攻击、Cloudware如何拒绝0-RTT请求并通过加密保护连接网络。感谢学而思网校架构师刘连响对本文的技术审校。

文 / Alessandro Ghedini

译 / Adrian Ng

技术审校 / 刘连响

原文 https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/

这是来自TLS 协议的最新版本TLS 1.3，原名称为 “zeroroundtrip time connection resumption”。这是一个可以允许客户端无需等待TLS握手完成就开始发送应用程序数据的操作模式，比如 HTTP请求，从而减少建立新连接所产生的延迟损失。

0-RTT 连接恢复的基本idea是- 如果客户机与服务器彼此之间曾经建立TLS连接，它们可以使用从该会话缓存的信息来建立新的TLS连接，而不必从头协商connection’sparameters。极大程度上这，这可以让客户端在于服务器对话之前计算保护applicationdata所需的private encryption data。

在此，TLS的 ”zero roundtrip” 仅指的是 TLS握手过程：为了能够交换TLS数据，客户端和服务器仍然需要首先建立TCP连接。

Zero means zero

另外，QUIC更近一步可以允许客户机在连接的第一个往返过程中发送applicationdata，不需涉及到其他的handshake。

毕竟，QUIC通过将connection’shandshake和cryptographic graphic合拼为一个handshake，已经缩短了典型连接握手的完整往返行程。在此减少了握手的额外roundtrip，QUIC即可建立实际的 0-RTT连接。

Attack of the clones

0-RTT连接恢复并非那么简单，它会带来许多意外风险及警告，这正是为什么Cloudfare默认程序不启用0-RTT连接恢复的原因。用户必须提前考虑所涉及的风险，并做出决定是否使用此功能。

首先，0-RTT连接恢复是不提供forwardsecrecy的，针对连接的secret parameters的妥协将微不足道地允许恢复新连接0-RTT阶段期间，发送applicationdata 进行特定的妥协。

在0-RTT阶段之后、或握手之后发送的数据，仍然是安全的。这是因为TLS1.3 (及QUIC)还是会对handshakecompletion之后发送的数据执行normal key exchange algorithm (这是forwardsecret) 。

值得注意的是，在0-RTT期间发送的applicationdata 可以被路径上的on-path attacker 捕获，然后多次重播到同一个服务器。这个在大部分情况下也许不是问题，因为attacker无法解密数据，0-RTT连接恢复还是非常有用的。在其他的情况下，这可能会引起出乎意料的风险。

举个比例，假设一家银行允许authenticated user (e.g using HTTPcookie, 或其他HTTP身份验证机制)通过specificAPI endpoint发出HTTP请求将资金从其账户发送到另一个用户。

如果attacker能够在使用0-RTT连接恢复时捕获该请求，他们将无法看到plaintext并且获取用户的凭据，原因是因为他们不知道用于加密数据的secretkey；但是他们仍然有可能一直散发重复性地请求，耗尽该用户的银行账户里的钱。

当然，这个问题并不限制于banking APIs；任何非幂等请求都有可能导致不必要的副作用，从轻微故障直到严重的安全漏洞都有可能发生。

为了降低这种风险，Cloudfare 始终都会拒绝一些不是等幂的0-RTT请求（例如POST或PUT请求）。最后，由位于Cloudfare背后的应用程序决定0-RTT连接能否接受这些请求，因为即使是看起来无害的请求也会对originserver产生副作用。

为了帮助origins 检测以及禁止一些特定请求，Cloudfare 还遵循RFC8470中所描述的技术。当然的，Cloudware会先将早期的Data:  1 HTTP header添加到0-RTT恢复期间，所接受到的转发到源请求。

Origins 可以从此头的起源做出 425（too early）HTTP statuscode的回答请求，此代码将指示发起请求的客户端重试发同一个请求。这只有在 TLS 或QUIC握手完毕之后启动，甚至可以作为CloudflareWorker的一部分实施。

这使得origins对于安全的端点进行0-RTT请求更有可能，例如网站的索引页面是对于0-RTT最有用处的地方。通常这是浏览器在建立连接之后发出的第一个请求，同时保护有如APIs和formsubmissions的endpoints。如果远点不提供这些non-idempotent端点，则不需要执行任何的操作。

One stop shop for all your 0-RTT needs

就像之前的TLS 1.3 ，我们现在已支持QUIC的0-RTT恢复。此外，我们已取消准许Cloudfare用户为其网站启用此功能的控制功能，引入了一个dedicatedtoggle来控制0-RTT连接恢复。这可以在Cloudfare仪表板的‘Network’选项卡表面下找到：

当 TLS1.3 和/或 QUIC(通过HTTP/3) 启用了，0-RTT连接恢复将自动地为客户端启动。上面提到的重播缓解也将会启用。

另外，如果你是我们NGINX开源HTTP/3 patch的用户，你需要等待patch最新版本的更新。通过使用内置的“ssl_early_data”选项，你并可以在自己基于NGINX的HTTP/3部署中启用对0-RTT连接恢复的支持，该选项将同时适用于TLS1.3和QUIC+HTTP/3。

LiveVideoStackCon 2020上海 讲师招募

2020年LiveVideoStackCon将持续迭代，4月在上海，9月在北京，11月在旧金山。欢迎将你的技术实践、踩坑与填坑经历、技术与商业创业的思考分享出来，独乐不如众乐。请将个人资料和话题信息邮件到 speaker@livevideostack.com 或点击【阅读原文】了解成为LiveVideoStackCon讲师的权益与义务，我们会在48小时内回复。