本文主要探討TLS協(xié)議，看看它如何允許客戶機(jī)開始發(fā)送HTTP要求，并且無需等待TLS握手完成即可減少延遲、建立更快的連接。此外，之中會(huì)有一些風(fēng)險(xiǎn)如通過API端點(diǎn)發(fā)送HTTP請(qǐng)求間的bank API重放攻擊、Cloudware如何拒絕0-RTT請(qǐng)求并通過加密保護(hù)連接網(wǎng)絡(luò)。感謝學(xué)而思網(wǎng)校架構(gòu)師劉連響對(duì)本文的技術(shù)審校。

文 / Alessandro Ghedini

譯 / Adrian Ng

技術(shù)審校 / 劉連響

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

這是來自TLS 協(xié)議的最新版本TLS 1.3，原名稱為 “zeroroundtrip time connection resumption”。這是一個(gè)可以允許客戶端無需等待TLS握手完成就開始發(fā)送應(yīng)用程序數(shù)據(jù)的操作模式，比如 HTTP請(qǐng)求，從而減少建立新連接所產(chǎn)生的延遲損失。

0-RTT 連接恢復(fù)的基本idea是- 如果客戶機(jī)與服務(wù)器彼此之間曾經(jīng)建立TLS連接，它們可以使用從該會(huì)話緩存的信息來建立新的TLS連接，而不必從頭協(xié)商connection’sparameters。極大程度上這，這可以讓客戶端在于服務(wù)器對(duì)話之前計(jì)算保護(hù)applicationdata所需的private encryption data。

在此，TLS的 ”zero roundtrip” 僅指的是 TLS握手過程：為了能夠交換TLS數(shù)據(jù)，客戶端和服務(wù)器仍然需要首先建立TCP連接。

Zero means zero

另外，QUIC更近一步可以允許客戶機(jī)在連接的第一個(gè)往返過程中發(fā)送applicationdata，不需涉及到其他的handshake。

?

畢竟，QUIC通過將connection’shandshake和cryptographic graphic合拼為一個(gè)handshake，已經(jīng)縮短了典型連接握手的完整往返行程。在此減少了握手的額外roundtrip，QUIC即可建立實(shí)際的 0-RTT連接。

Attack of the clones

0-RTT連接恢復(fù)并非那么簡(jiǎn)單，它會(huì)帶來許多意外風(fēng)險(xiǎn)及警告，這正是為什么Cloudfare默認(rèn)程序不啟用0-RTT連接恢復(fù)的原因。用戶必須提前考慮所涉及的風(fēng)險(xiǎn)，并做出決定是否使用此功能。

首先，0-RTT連接恢復(fù)是不提供forwardsecrecy的，針對(duì)連接的secret parameters的妥協(xié)將微不足道地允許恢復(fù)新連接0-RTT階段期間，發(fā)送applicationdata 進(jìn)行特定的妥協(xié)。

在0-RTT階段之后、或握手之后發(fā)送的數(shù)據(jù)，仍然是安全的。這是因?yàn)門LS1.3 (及QUIC)還是會(huì)對(duì)handshakecompletion之后發(fā)送的數(shù)據(jù)執(zhí)行normal key exchange algorithm (這是forwardsecret) 。

值得注意的是，在0-RTT期間發(fā)送的applicationdata 可以被路徑上的on-path attacker 捕獲，然后多次重播到同一個(gè)服務(wù)器。這個(gè)在大部分情況下也許不是問題，因?yàn)閍ttacker無法解密數(shù)據(jù)，0-RTT連接恢復(fù)還是非常有用的。在其他的情況下，這可能會(huì)引起出乎意料的風(fēng)險(xiǎn)。

舉個(gè)比例，假設(shè)一家銀行允許authenticated user (e.g using HTTPcookie, 或其他HTTP身份驗(yàn)證機(jī)制)通過specificAPI endpoint發(fā)出HTTP請(qǐng)求將資金從其賬戶發(fā)送到另一個(gè)用戶。

如果attacker能夠在使用0-RTT連接恢復(fù)時(shí)捕獲該請(qǐng)求，他們將無法看到plaintext并且獲取用戶的憑據(jù)，原因是因?yàn)樗麄儾恢烙糜诩用軘?shù)據(jù)的secretkey；但是他們?nèi)匀挥锌赡芤恢鄙l(fā)重復(fù)性地請(qǐng)求，耗盡該用戶的銀行賬戶里的錢。

當(dāng)然，這個(gè)問題并不限制于banking APIs；任何非冪等請(qǐng)求都有可能導(dǎo)致不必要的副作用，從輕微故障直到嚴(yán)重的安全漏洞都有可能發(fā)生。

為了降低這種風(fēng)險(xiǎn)，Cloudfare 始終都會(huì)拒絕一些不是等冪的0-RTT請(qǐng)求（例如POST或PUT請(qǐng)求）。最后，由位于Cloudfare背后的應(yīng)用程序決定0-RTT連接能否接受這些請(qǐng)求，因?yàn)榧词故强雌饋頍o害的請(qǐng)求也會(huì)對(duì)originserver產(chǎn)生副作用。

為了幫助origins 檢測(cè)以及禁止一些特定請(qǐng)求，Cloudfare 還遵循RFC8470中所描述的技術(shù)。當(dāng)然的，Cloudware會(huì)先將早期的Data:? 1 HTTP header添加到0-RTT恢復(fù)期間，所接受到的轉(zhuǎn)發(fā)到源請(qǐng)求。

Origins 可以從此頭的起源做出 425（too early）HTTP statuscode的回答請(qǐng)求，此代碼將指示發(fā)起請(qǐng)求的客戶端重試發(fā)同一個(gè)請(qǐng)求。這只有在 TLS 或QUIC握手完畢之后啟動(dòng)，甚至可以作為CloudflareWorker的一部分實(shí)施。

這使得origins對(duì)于安全的端點(diǎn)進(jìn)行0-RTT請(qǐng)求更有可能，例如網(wǎng)站的索引頁面是對(duì)于0-RTT最有用處的地方。通常這是瀏覽器在建立連接之后發(fā)出的第一個(gè)請(qǐng)求，同時(shí)保護(hù)有如APIs和formsubmissions的endpoints。如果遠(yuǎn)點(diǎn)不提供這些non-idempotent端點(diǎn)，則不需要執(zhí)行任何的操作。

?

One stop shop for all your 0-RTT needs

就像之前的TLS 1.3 ，我們現(xiàn)在已支持QUIC的0-RTT恢復(fù)。此外，我們已取消準(zhǔn)許Cloudfare用戶為其網(wǎng)站啟用此功能的控制功能，引入了一個(gè)dedicatedtoggle來控制0-RTT連接恢復(fù)。這可以在Cloudfare儀表板的‘Network’選項(xiàng)卡表面下找到：

當(dāng) TLS1.3 和/或 QUIC(通過HTTP/3) 啟用了，0-RTT連接恢復(fù)將自動(dòng)地為客戶端啟動(dòng)。上面提到的重播緩解也將會(huì)啟用。

另外，如果你是我們NGINX開源HTTP/3 patch的用戶，你需要等待patch最新版本的更新。通過使用內(nèi)置的“ssl_early_data”選項(xiàng)，你并可以在自己基于NGINX的HTTP/3部署中啟用對(duì)0-RTT連接恢復(fù)的支持，該選項(xiàng)將同時(shí)適用于TLS1.3和QUIC+HTTP/3。

LiveVideoStackCon 2020上海?講師招募

2020年LiveVideoStackCon將持續(xù)迭代，4月在上海，9月在北京，11月在舊金山。歡迎將你的技術(shù)實(shí)踐、踩坑與填坑經(jīng)歷、技術(shù)與商業(yè)創(chuàng)業(yè)的思考分享出來，獨(dú)樂不如眾樂。請(qǐng)將個(gè)人資料和話題信息郵件到?speaker@livevideostack.com?或點(diǎn)擊【閱讀原文】了解成為L(zhǎng)iveVideoStackCon講師的權(quán)益與義務(wù)，我們會(huì)在48小時(shí)內(nèi)回復(fù)。

總結(jié)

以上是生活随笔為你收集整理的通过QUIC 0-RTT建立更快的连接的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。