臉書對外開源其新一代傳輸層安全性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協定工作。


Advertisement

更多 iThome相關內容