臉書開源其每秒處理數百萬次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協議工作。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！