三種方法實現移動端HTTPS的加速和省電

做者：王繼波
野狗科技運維總監，曾在360、TP-Link從事網絡運維相關工做，在網站性能優化、網絡協議研究上經驗豐富。
野狗官博：https://blog.wilddog.com/
野狗官網：https://www.wilddog.com/
公衆訂閱號：wilddogbaas

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上的相關文章：
https://community.qualys.com/blogs/securitylabs/2013/03/19/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。

關於AES-NI的指令集，推薦查看Shay Gueron編寫的《Intel 高級加密標準 (AES) 指令集 (2010)》。https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set

ChaCha20-Poly1305優點何在？

Google推出新的加密套件並在全部移動端的Chrome瀏覽器上優先使用緣由：

1. ChaCha20-Poly1305避開了現有發現的全部安全漏洞和攻擊；

2. ChaCha20-Poly1305針對移動端設備大量使用的ARM芯片作了優化，可以充分利用ARM向量指令，在移動設備上加解密速度更快、更省電；

3. 更加節省帶寬，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官方的動態（https://www.openssl.org/news/changelog.html ）。

在Nginx上實現ChaCha20-Poly1305主流的方法有三種：

1. 使用OpenBSD從OpenSSL fork的分支LibreSSL；

2. 使用Google從OpenSSL fork的分支BoringSSL；

3. 使用CloudFlare提供的OpenSSL Patch。

主流的三種方法，都已經在服務器上部署成功並通過流量測試，各有優缺點。具體的部署方法、Nginx配置、部署過程可能會遇到的錯誤及解決方法，涉及的內容太多，相關內容以下：

• Nginx編譯安裝BoringSSL

• Nginx編譯安裝LibreSSL

• Nginx編譯安裝CloudFlare提供的OpenSSL Patch

下面是我總結的這三種方法的優缺點，這個歡迎你們補充。

LibreSSL

1. 編譯安裝方法最爲簡單；

2. OpenBSD小組對OpenSSL的代碼進行了全面清理並重構，更爲輕量；

3. 已經發布穩定版本，相比於OpenSSL團隊，問題修復更及時。

BoringSSL

1. 支持等價加密算法組功能（Equal preference cipher groups），這功能我認爲頗有意思，在後面博客中再介紹；

2. 與Nginx編譯友好性不足，編譯容易出錯，至少須要修改兩處源碼；

3. 不支持OCSP Stapling功能。這一點是比較有意思的，Google工程師在博客上說OCSP Stapling存在缺陷，目前不支持，但不排除後面支持的可能性。聯想到Chrome瀏覽器默認也不使用OCSP，可見Google對OCSP的情感是複雜的。
   https://www.imperialviolet.org/2014/04/19/revchecking.html

OpenSSL Patch

1. 編譯安裝過程較爲複雜；

2. OpenSSL自己較重，存在的安全問題也多，須要頻繁升級版本；

3. 穩定性須要進一步驗證。

目前野狗WildDog網站使用的是LibreSSL，來解決移動端的加速省電等新性能，若是你有疑問，或者想更多交流，或者在使用ChaCha20-Poly1305時遇到問題，都歡迎和咱們聯繫。最後附上野狗官網（www.wilddog.com）在ssllabs上評測結果中截圖。