每天都有數十億人在Android和iOS裝置上通過Facebook與朋友建立聯絡。對我們移動應用和伺服器之間傳輸的資料提供保護，可以幫助人們更安全地使用Facebook。

我們的移動應用使用了一種名為Mobile Proxygen的自定義網路棧，這是一種使用C++14開發的跨平臺HTTP客戶端，使用我們自己的開源Proxygen庫構建而來。藉此我們可以在伺服器和客戶端之間共享同一套程式碼，更快速地提供新的安全和效能改進。

我們在移動應用中使用了傳輸層安全（TLS）1.2協議，並使用帶OpenSSL的Folly作為TLS的具體實現。由於增加了至少一輪往返，TLS 1.2會延長建立連線所需的時間，為了降低TLS的延遲，過去多年來人們提出了多種新的協議和改進。Facebook傳輸安全團隊曾通過多種方式設法儘可能改善TLS的速度，包括通過技術手段在距離使用者最近的邊緣位置終止TLS連線，重複使用HTTP2連線，使用會話重用（Session resumption）和TLS搶跑（False start），推斷式連線啟動，以及使用現代化的Cipher套件。從我們的移動應用到Facebook建立的大部分TLS連線僅額外增加了一輪往返（1-RTT）。

回顧一年前的資料，我們發現在建立連線的過程中，1-RTT優化後的安全握手過程依然需要較長的時間。例如在印度等新興市場，使用者往往要花費600ms（75百分位數）的時間才能建立TLS連線。我們認為有必要採取一些措施，降低這些請求的延遲，進而減少建立安全連線所需的時間。

我們打算使用零往返（0-RTT）安全協議進行一些實驗。與TLS 1.2等1-RTT安全協議不同，這些協議意在確保安全性，並且不產生額外的往返延遲的前提下建立安全的連線。TCP已經深度融入到我們的基礎架構中，為了避免一次性對整個基礎架構進行較大的調整，我們希望逐步進行這樣的實驗。同樣基於TCP協議的TLS 1.3目前提供了0-RTT功能，然而在我們研究各類選項的時候，TLS 1.3還處於萌芽狀態，暫未提供0-RTT功能。此外還可以選擇基於UDP的QUIC，這也是一種0-RTT協議，在分析過該協議的安全模式後，很多學術機構對該協議的加密模式產生了一定的關注。我們希望讓基於UDP的QUIC所具備的低延遲特效能夠適用於TCP，藉此更快速地建立安全連線，因此我們使用QUIC加密協議構建了一個基於TCP的實驗性零往返協議。

過去一年來，我們已經為移動應用和負載均衡器構建並部署了零往返協議，並獲得了顯著的效能改進，例如連線延遲降低了41%，處理請求的總時間降低了2%。在有關0-RTT協議的實踐過程中，我們還收穫了很多寶貴的工程經驗，例如API設計、安全屬性，以及部署，並將我們的一些成果貢獻給了業已成熟的TLS 1.3。希望我們通過本文分享的經驗也能適用於未來打算部署TLS 1.3的應用。

為了使其更加安全和高效，我們在零往返協議中對QUIC加密模式進行了大量改動。此外我們還設法讓該協議可以通過TCP執行。因此可以認為，我們的零往返協議是在原本QUIC加密規範基礎上進行的一系列改進。本節將介紹有關加該協議密碼學的相關細節，以及幫助大家理解這一加密模式所需掌握的相關知識。

概括來看，QUIC的加密協議是這樣工作的：如果某個客戶端以前從未與伺服器通訊過，會發送一則Inchoate Client Hello訊息並通過1-RTT下載一個名為Server Config（SCFG）的暫存訊息。該訊息中包含一個Diffie-Hellman共享，下一次客戶端將使用該共享派生初始金鑰（或0-RTT金鑰），並立刻使用該金鑰加密資料。1-RTT完成後，伺服器將發出一個新的暫存Diffie-Hellman共享，藉此派生出一組名為前向（Forward）安全金鑰的新金鑰。

原始的QUIC規範包含兩種型別的金鑰：

• 初始金鑰（或0-RTT金鑰），用於傳送初始資料，可從長存的伺服器配置中派生而來。前向安全金鑰（或1-RTT金鑰），用於在伺服器向客戶端傳送Server Hello訊息後傳輸資料所用。

• 客戶端傳送Client Hello（CHLO）後，伺服器使用加密的Server Hello（SHLO）訊息作為迴應。其中包一組新的公鑰（PUBS），這是一種可用於派生出Forward安全金鑰的Diffie-Hellman共享。該訊息會使用初始0-RTT金鑰進行加密，伺服器通過正確解密SHLO可成功完成身份驗證。

然而我們發現這種金鑰派生方法存在金鑰被重複使用的弱點。初始金鑰以及對SHLO進行的現時（Nonce）加密完全是通過Client Hello訊息派生而來的，因此如果攻擊者“重播”相同的CHLO，伺服器會使用相同金鑰對不同的SHLO訊息進行現時加密。AEAD密碼演算法的安全特性被破壞了，進而威脅到QUIC的安全性，除非我們能通過額外的有狀態方法檢測相同的CHLO訊息。

在零往返協議中，我們引入了另一種通過明文方式傳輸的現時機制，並會通過一個新的金鑰加密SHLO。此外我們也已經將該弱點報告給谷歌，他們為QUIC提供的“多樣化現時（Diversification nonce）”解決了這個問題。

我們對伺服器配置（Server Config）的有效時間進行了限制，原因在於，如果該配置在有效時段內被盜，將能被一直用於冒充伺服器。在QUIC協議中，讓包含已快取老舊SCFG的客戶端使用新SCFG的唯一方法是繼續使用原來的SCFG，被拒絕，然後獲得新的SCFG。這種方法的不足之處在於，如果客戶端傳送了0-RTT資料，在輪換配置時必須丟棄這些資料並進行重播。

我們對協議進行了改進，使得我們可以在帶內（In-band）直接傳送新的SCFG。伺服器隨時維護著包含三個配置的清單：上一個配置、當前配置，以及下一個配置。如果檢測到客戶端在使用老的SCFG，我們會讓客戶端完成連線，隨後通過加密的SHLO為客戶端提供新的SCFG，進而客戶端可以將自己的SCFG更新為新版本。這種方式可以避免客戶端因為使用老舊配置而被拒絕的退化情況。

TLS 1.2還提供了一種通過重新整理會話票證（Session Ticket）實現相同目的的做法，然而這種方法無法保障前向安全，因為新老會話票證會共享同一個主金鑰。在QUIC協議中，新金鑰需要另一個Diffie-Hellman操作，重新整理後可以保證前向安全。

就算通過帶內的方式重新整理伺服器配置，依然會遇到客戶端繼續使用老配置的情況。此時無法避免要拒絕客戶端並回退至1-RTT，但連線依然無法防範重播。客戶端可以傳送0-RTT資料，但不能立刻傳送常規資料。

我們對零往返協議進行了效能優化，可以在客戶端的伺服器配置被拒絕的時間段內向客戶端傳送額外的伺服器現時，這樣即可使用該現時，立即開始傳送常規的1-RTT非重播安全資料。

相比通過1-RTT或TLS 1.2等協議傳送的常規資料，0-RTT資料有著不同的安全特性。與常規的1-RTT資料不同，攻擊者可以無窮盡地重播0-RTT資料，如果應用無法妥善地保護自己，這會造成一種非常有意思的攻擊。例如，攻擊者可以將一個HTTP POST請求重播兩次，並在缺乏遏制機制的情況下讓該請求被執行兩次。攻擊者還可以將發往銀行的同一個GET請求重播任意次數，通過檢視響應的長度判斷銀行賬戶餘額的變化情況。0-RTT資料必須以截然不同的方式妥善應對。1-RTT完成後，客戶端將可以傳送任何資料，因為連線又可以防範重播了。

我們使用的一種緩解措施是減小0-RTT的有效時長。客戶端可以向我們傳送啟動連線的時間，我們會將該時間與伺服器時間進行對比，以確定該0-RTT資料是在多久之前建立的。如果0-RTT資料在有效期過期之後重播，伺服器將拒絕這樣的資料，藉此禁止攻擊者無窮盡地重播這些資料。然而隨著降低有效期，我們發現很多客戶端的時鐘存在較大偏差，進而產生了很多誤報。

為了解決這個問題，當客戶端成功連線後，我們會下發一個時鐘偏差校正值。客戶端下一次連線時，需要這樣計算自己的客戶端時間：

client_time = client_real_time + clock_skew_correction

我們還發現客戶端的時鐘偏差存在一定的方差，但由於該方差並不是那麼大，因此可以強制實施嚴格的0-RTT資料有效期。

為了相容TCP，我們在零往返協議中取消了QUIC資料包的顯式序列編號，並增加了顯式長度欄位。QUIC是基於UDP的，因此不需要長度欄位，而由於UDP資料包可以重新排序，因此必須具備顯式序列編號。