通过QUIC 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连接。

通过QUIC 0-RTT建立更快的连接

Zero means zero


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

通过QUIC 0-RTT建立更快的连接

毕竟,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;但是他们仍然有可能一直散发重复性地请求,耗尽该用户的银行账户里的钱。

通过QUIC 0-RTT建立更快的连接

当然,这个问题并不限制于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


「视频云技术」你最值得关注的音视频技术公众号,每周推送来自阿里云一线的实践技术文章,在这里与音视频领域一流工程师交流切磋。

通过QUIC 0-RTT建立更快的连接

上一篇:网宿科技业绩大跌 CDN行业面临洗牌


下一篇:尼日利亚的学生开发者,用阿里云PAI打造了卡通头像神器