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

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

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

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%。

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

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協議工作。


分享到:


相關文章: