本文為野狗科技投稿
HTTPS網站的普及使大家更加關注HTTPS性能優化,一般做HTTPS優化可能只是針對PC端,在移動端的效果並不理想。去年Google就已經在移動端做了HTTPS的性能加速,為Android平台的Chrome浏覽器增加了一個新的TLS加密套件:ChaCha20-Poly1305,這是專門為移動設備推出的加密套件。接下來我們深入探討如何使用ChaCha20-Poly1305加密套件實現HTTPS移動端加速和省電。
下圖是在iPhone Chrome上打開Google日本網站後的加密信息截圖。
野狗WildDog已經全站支持在移動設備上更高性能、更省電的加密套件ChaCha20-Poly1305。下面是在Chrome上打開野狗官網的加密信息截圖。
為了能夠更好的了解ChaCha20-Poly1305,先簡單介紹對稱加密和AES-NI。
對稱加密與AES-NI
對稱加密
在HTTPS握手過程,通過非對稱加密協商出對稱加密密鑰,然後使用對稱加密對雙方通信的數據內容進行加密。非對稱加密是服務器性能的開銷是巨大的,通過Session Resume等方法可以進行加速。常見的非對稱加密算法有RSA、ECDHE等。
在協商出對稱加密密鑰後,HTTPS中所有數據內容通信的加密都使用對稱加密進行。對稱加密分為流式加密和分組加密。
常見的流式加密算法有:RC4,ChaCha20-Poly1305。
常見的分組加密算法有:AES-CBC,AES-GCM。
RC4由於存在嚴重安全漏洞,已經基本不再使用;AES-CBC容易遭受BEAST和LUCKY13攻擊,使用也逐漸減少,AES-GCM是它們的安全替代,AES-GCM也是目前最為流行的對稱加密算法。
安全風險可參看ssllabs上的相關文章:Ivan Ristic RC4 in TLS is Broken: Now What?
AES-NI
AES-GCM解決了對稱加密存在的安全問題,但帶來了性能問題。為此,出現了AES-NI(Advanced Encryption Standard New Instruction)。AES-NI是Intel和AMD微處理器上x86架構的一個擴展,可以從硬件上加速AES的性能,目前在服務器和PC端,CPU對AES-NI的支持率已經非常普及。
測試結果:服務器開啟AES-NI後,性能提高了5-8倍左右,這與Intel官方公布的數據基本是一致的。
測試方法:
可以使用OpenSSL測試也可以使用其他SSL庫測試,因為所有SSL庫都支持AES-128-GCM。
OpenSSL AES-NI = OFF # OPENSSL_ia32cap=”~0x200000200000000″ openssl speed -elapsed -evp aes-128-gcm OpenSSL AES-NI = ON # openssl speed -elapsed -evp aes-128-gcm
關於AES-NI的指令集,推薦查看Shay Gueron編寫的《Intel 高級加密標准 (AES) 指令集 (2010)》。
ChaCha20-Poly1305優勢何在?
Google推出新的加密套件並在所有移動端的Chrome浏覽器上優先使用原因:
ChaCha20-Poly1305避開了現有發現的所有安全漏洞和攻擊;
ChaCha20-Poly1305針對移動端設備大量使用的ARM芯片做了優化,能夠充分利用ARM向量指令,在移動設備上加解密速度更快、更省電;
更加節省帶寬,Poly1305的輸出是16字節,而HMAC-SHA1是20字節,可以節省16%的overhead消耗。
通過實際的測試數據來看看ChaCha20-Poly1305在移動端使用的優勢。
測試一:
在支持AES-NI擴展的設備上,AES加密的性能優勢是明顯的。 目前最為常用的對稱加密AES-128-GCM的性能是ChaCha20-Poly1305的近5倍。
由於原生的OpenSSL目前還不支持ChaCha20-Poly1305,通過編譯LibreSSL源碼(最新源碼下載地址:http://ftp.openbsd.org/pub/OpenBSD/LibreSSL)來進行測試。
測試方法:
進入到編譯後的LibreSSL目錄,通過下面的命令測試。
./apps/openssl/openssl speed -elapsed -evp chacha ./apps/openssl/openssl speed -elapsed -evp aes-128-gcm ./apps/openssl/openssl speed -elapsed -evp aes-256-gcm ./apps/openssl/openssl speed -elapsed -evp aes-128-cbc ./apps/openssl/openssl speed -elapsed -evp aes-256-cbc
測試二:
在不支持AES-NI擴展的移動設備上,ChaCha20-Poly1305的性能是AES-GCM的三倍左右。
對稱加密最合理的使用方法是:在支持AES-NI的設備上,優先使用AES-128-GCM加密套件;在不支持AES-NI的移動設備上,特別是ARM架構的設備上,優先使用ChaCha20-Poly1305加密套件。
Nginx實現ChaCha20-Poly1305的三種方法
OpenSSL官方版本目前不支持ChaCha20-Poly1305,所以不能使用原生的OpenSSL版本(關注OpenSSL官方的動態)。
在Nginx上實現ChaCha20-Poly1305主流的方法有三種:
使用OpenBSD從OpenSSL fork的分支LibreSSL;
使用Google從OpenSSL fork的分支BoringSSL;
使用CloudFlare提供的OpenSSL Patch。
主流的三種方法,都已經在服務器上部署成功並經過流量測試,各有優缺點。具體的部署方法、Nginx配置、部署過程可能會遇到的錯誤及解決方法,涉及的內容太多,相關內容如下:
Nginx編譯安裝BoringSSL
Nginx編譯安裝LibreSSL
Nginx編譯安裝CloudFlare提供的OpenSSL Patch
下面是我總結的這三種方法的優缺點,這個歡迎大家補充。
LibreSSL
編譯安裝方法最為簡單;
OpenBSD小組對OpenSSL的代碼進行了全面清理並重構,更為輕量;
已經發布穩定版本,相比於OpenSSL團隊,問題修復更及時。
BoringSSL
支持等價加密算法組功能(Equal preference cipher groups),這功能我認為很有意思,在後面博客中再介紹;
與Nginx編譯友好性不足,編譯容易出錯,至少需要修改兩處源碼;
不支持OCSP Stapling功能。這一點是比較有意思的,Google工程師在博客上說OCSP Stapling存在缺陷,目前不支持,但不排除後面支持的可能性。聯想到Chrome浏覽器默認也不使用OCSP,可見Google對OCSP的情感是復雜的。
OpenSSL Patch
編譯安裝過程較為復雜;
OpenSSL本身較重,存在的安全問題也多,需要頻繁升級版本;
穩定性需要進一步驗證。
目前野狗WildDog網站使用的是LibreSSL,來解決移動端的加速省電等新性能,如果你有疑問,或者想更多交流,或者在使用ChaCha20-Poly1305時遇到問題,都歡迎和我們聯系。最後附上野狗官網(www.wilddog.com)在ssllabs上評測結果中截圖。