三种方法实现移动端 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 浏览器上优先使用原因：

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 官方的动态（ 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

OpenSSL Patch

编译安装过程较为复杂；
OpenSSL 本身较重，存在的安全问题也多，需要频繁升级版本；
稳定性需要进一步验证。

目前野狗 WildDog 网站使用的是 LibreSSL ，来解决移动端的加速省电等新性能，如果你有疑问，或者想更多交流，或者在使用 ChaCha20-Poly1305 时遇到问题，都欢迎和我们联系。最后附上野狗官网（ www.wilddog.com ）在 ssllabs 上评测结果中截图。