臉書開源其每秒處理數百萬次TLS交握的高效函式庫Fizz

臉書對外開源其新一代傳輸層安全性TLS 1.3協定函式庫Fizz，臉書提到，現在他們有一半以上的網際網路流量皆以TLS 1.3保護，每秒處理數百萬次TLS交握，而新協定的功能0-RTT不僅降低了延遲，也替臉書每天減少數兆的服務請求CPU使用率。透過開源Fizz，臉書要讓TLS 1.3更加普及。

TLS 1.3在今年3月底時已經拍板定案，重要的功能包括加密交握訊息，以確保憑證私密性，還重新設計了密鑰導出方法，並且加入降低延遲的0-RTT（Zero Round Trip Time Resumption）技術。TLS 1.3不只提供最新的安全加密技術，還能減少延遲和運算資源使用率，因此對於擁有超過十億用戶的臉書來說，部署TLS 1.3成為一件重要的事，臉書為此開發了自家的TLS函式庫Fizz。

Fizz以C++ 14撰寫而成，是一個主打高效能且多功能的TLS函式庫，現在臉書在全球的行動應用程式、HTTP函式庫與伺服器Proxygen、企業內部服務甚至是QUIC和mvfst，全都部署了Fizz和TLS 1.3，大規模採用的情況下，臉書有超過50％的流量都以TLS 1.3保護，並且臉書還使用了TLS 1.3的最新功能0-RTT，來減少服務延遲。

效能一直是加密的權衡要點之一，網際網路工程任務小組（Internet Engineering Task Force，IETF）在訂定TLS 1.3協定時，也把效能考慮進去。臉書與IETF長期密切合作，在增加TLS安全性的同時，也沒有忽略效能的重要性，過去他們使用了自定義的零協定（Zero Protocol），率先實驗建立0-RTT安全連接。使用0-RTT資料可以減少部署TLS的帶來的請求延遲，以及延遲成本開支，臉書現在以TLS 1.3取代了自行開發的零協定。

臉書分析到，與TLS 1.2相比，TLS 1.3早期資料（Early Data）在建立安全連線時，延遲明顯減少，這能大幅提升使用者經驗，尤其在應用程式冷啟動，尚未存在任何可重複使用的連線時。臉書公布其在Android平臺的應用程式測試結果，TLS 1.3早期資料比起TLS 1.2，在第50百分位數，連線建立階段延遲可以減少46％，而在新連線HTTP請求延遲則減少10％。

Fizz提供了易於使用的API，讓開發者可以在TCP連線建立後，立刻送出早期資料，而從臉書提供的資料顯示，這對於減少行動裝置應用程式的冷啟動延遲非常重要。但臉書提醒，早期資料有其風險，因為駭客能夠輕易透過重播資料，來讓伺服器重複處理工作，為了降低這個攻擊風險，臉書只傳送在特定白名單中的請求作為早期資料，並且在負載平衡器中部署了重播快取，用來偵測並拒絕資料重播。

另外，Fizz還提供了零複製寫入功能，進一步提升了加密應用效能。臉書提到，不少支援TLS的函式庫都要求使用者提供完整連續的記憶體區塊，TLS函式庫會加密這些資料並且寫入到Socket中，但通常裝置中，應用程式會使用多個記憶體區塊保存資料，因此應用程式需要把這些資料複製到連續的記憶體區塊，供TLS函式庫加密使用，而搬移資料的動作，增加了延遲開支。

而對於分散或是單一區塊的記憶體資料，Fizz都能良好的處理，該函式庫提供I/O的API，預設接受分散與聚集抽象輸入，因此即便資料散落在記憶體各處，應用程式也不須要再花一道手續集中資料，不只更省時間，也減少了複製所佔用的記憶體，因此Fizz能以更省的硬體資源處理加密工作。

臉書提到，TLS狀態機很複雜，過去的漏洞都發生在TLS實作中的狀態機。而Fizz為了管理複雜的TLS狀態機，讓狀態機資訊外顯，也就是說狀態機的狀態被定義在單一位置，並根據收到的訊息轉換狀態，臉書提到，將狀態明確定義在單個位置就可以解決這類安全問題。

臉書在部署TLS 1.3並不順利，遇到非常多的問題，不少是發生在網際網路中介裝置上，可能由於對TLS不容錯，而拋棄TLS協定交握或是重置連線。臉書透過與Firefox和Chrome合作，在多個協定變體上實驗，在Fizz上修正了交握方法，並增加了數個變通方法來減少網路中介裝置對於早期資料的干擾，因此Fizz現在已經能非常強健的處理TLS協定工作。