开发者社区> 视频云技术> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

简介: 本文主要探讨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连接。

image.png

Zero means zero


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

image.png

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

image.png

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


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

阿里云视频云@凡科快图的副本.png

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Struts2利用验证框架实现数据验证(十一)下
Struts2利用验证框架实现数据验证(十一)
34 0
AliOS Things技术底层加持平头哥YoC物联网操作系统 获国际TUeV功能安全认证
近日,以阿里云物联网操作系统AliOS Things技术底层加持、平头哥半导体有限公司自主研发的YoC软件平台斩获了国际公认第三方认证机构SGS-TUeV SAAR颁发的SIL3功能安全证书。这标志着平头哥YoC软件平台,具备了与国际规范接轨的能力,也进一步体现了阿里云自产自研的AliOS Things系统底层的技术含量与端侧实力。
58 0
【52ABP实战教程】0.3-- 从github推送代码回vsts实现双向同步
需求 在之前的文章中“[DevOps]如何用VSTS持续集成到Github仓库” 我们有讲述如何将vsts中的代码编译推送到github中,这一篇我们来完善,如果有人给你开源项目推送了代码,你审核后,如何自动将代码推送回vsts,从而实现双同步。
920 0
HTTP协议建立连接、通讯与关闭连接全过程
为解决服务器TimeWait多的问题,了解了一下TCP/IP协议的连接过程。以访问一静态页面为例,从建立连接到访问拿到数据,然后关闭的整个过程。使用EtherPeek截图如下:   图首为一次交互过程的总览,图中用圈圈+颜色标注了连接过程中数据的变化过程。
1196 0
257
文章
2
问答
来源圈子
更多
+ 订阅
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载