通過QUIC 0-RTT建立更快的連接

• 2019 年 12 月 25 日
• 筆記

本文主要探討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連接。

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。