转载

如何实现HTTPS在移动端的性能优化

HTTPS网站的普及使大家更加关注HTTPS性能优化，一般做HTTPS优化可能只是针对PC端，但在移动端的效果并不理想。去年Google就已经在移动端做了HTTPS的性能加速，为Android平台的Chrome浏览器上增加一个新的TLS加密套件：ChaCha20-Poly1305，是专门为移动设备推出的加密套件，为了能提供更好的安全和性能。

下图是在iPhone Chrome上打开Google日本网站后的加密信息截图。

如何实现HTTPS在移动端的性能优化

野狗WildDog已经全站支持在移动设备上更高性能、更省电的加密套件ChaCha20-Poly1305。下面是在Chrome上打开野狗官网的加密信息截图。

如何实现HTTPS在移动端的性能优化

为了能够更好的了解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官方公布的数据基本是一致的。

如何实现HTTPS在移动端的性能优化

测试方法：

可以使用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)》。https://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set

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

如何实现HTTPS在移动端的性能优化

由于原生的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的三倍左右。

如何实现HTTPS在移动端的性能优化

对称加密最合理的使用方法是：在支持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主流的方法有三种：

使用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的情感是复杂的。https://www.imperialviolet.org/2014/04/19/revchecking.html