本文主要探討TLS協(xié)議，看看它如何允許客戶機(jī)開始發(fā)送HTTP要求，并且無需等待TLS握手完成即可減少延遲、建立更快的連接。此外，之中會有一些風(fēng)險如通過API端點發(fā)送HTTP請求間的bank API重放攻擊、Cloudware如何拒絕0-RTT請求并通過加密保護(hù)連接網(wǎng)絡(luò)。感謝學(xué)而思網(wǎng)校架構(gòu)師劉連響對本文的技術(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”。這是一個可以允許客戶端無需等待TLS握手完成就開始發(fā)送應(yīng)用程序數(shù)據(jù)的操作模式，比如 HTTP請求，從而減少建立新連接所產(chǎn)生的延遲損失。

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

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

Zero means zero

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

?

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

Attack of the clones

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

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

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

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

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

如果attacker能夠在使用0-RTT連接恢復(fù)時捕獲該請求，他們將無法看到plaintext并且獲取用戶的憑據(jù)，原因是因為他們不知道用于加密數(shù)據(jù)的secretkey；但是他們?nèi)匀挥锌赡芤恢鄙l(fā)重復(fù)性地請求，耗盡該用戶的銀行賬戶里的錢。

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

為了降低這種風(fēng)險，Cloudfare 始終都會拒絕一些不是等冪的0-RTT請求（例如POST或PUT請求）。最后，由位于Cloudfare背后的應(yīng)用程序決定0-RTT連接能否接受這些請求，因為即使是看起來無害的請求也會對originserver產(chǎn)生副作用。

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

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

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

?

One stop shop for all your 0-RTT needs

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

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

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

LiveVideoStackCon 2020上海?講師招募

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

總結(jié)

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

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