三种方法实现移动端 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 上评测结果中截图。