文 / 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。
————————————————
版权声明：本文为CSDN博主「LiveVideoStack_」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/103692405
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。
