前不久，一位朋友在我博客评论中，问到：类似于 Google 那样电脑访问使用 AES，手机访问使用 CHACHA20 的算法是怎么实现的（详情）。最近我抽空研究了一下这个问题，现在我的博客也支持这个特性了。今天抽空介绍一下我的实现步骤，供愿意折腾的朋友们参考。
对称内容加密
我们知道，每个 TLS 会话都是在握手阶段通过非对称加密得出对称加密密钥，而本次会话双方一直会用这个密钥进行流量的对称加密。这样做是出于性能考虑，毕竟对称加密速度要快得多，更适合全流量使用。
对称加密算法有流式、分组两种。RC4 就是一个常见的流式加密算法，不过已被证实不再安全，应该停止使用。Google 推出了一种名为 ChaCha20-Poly1305 的流式加密新算法，已经内置于各大平台的 Chrome 之中。ChaCha20 除了更安全，还针对 ARM 做了优化，在移动设备上使用速度更快、更省电。以下是它与 AES-GCM 在加密速度上的对比（ via ）：
AES-GCM 是目前推荐使用的分组加密模式，它的缺点是计算量大，导致性能和电量开销比较大。为此，Intel 推出了一个名为 AES NI（Advanced Encryption Standard new instructions）的 x86 指令集扩展，从硬件上提供对 AES 的支持（ 详情 ）。Intel 自家 CPU 从 Westmere 平台开始支持 AES-NI，目前在 PC 端 AES-NI 的普及率显然很高。对于支持 AES-NI 的设备来说，使用 AES-GCM 加密算法无疑是最优选择，以下是一份对比（测试使用支持 AES-NI 的 Intel Xeon E3-1220 V2 @ 3.10GHz， via ）：
Did 20341000 AES-128-GCM (16 bytes) seal operations in 3000099us (6780109.6 ops/sec): 108.5 MB/s Did 2356000 AES-128-GCM (1350 bytes) seal operations in 3000761us (785134.2 ops/sec): 1059.9 MB/s Did 438000 AES-128-GCM (8192 bytes) seal operations in 3002910us (145858.5 ops/sec): 1194.9 MB/s Did 17839000 AES-256-GCM (16 bytes) seal operations in 3000160us (5946016.2 ops/sec): 95.1 MB/s Did 2092000 AES-256-GCM (1350 bytes) seal operations in 3000884us (697127.9 ops/sec): 941.1 MB/s Did 388000 AES-256-GCM (8192 bytes) seal operations in 3004207us (129152.2 ops/sec): 1058.0 MB/s Did 7779000 ChaCha20-Poly1305 (16 bytes) seal operations in 3000332us (2592713.1 ops/sec): 41.5 MB/s Did 1139000 ChaCha20-Poly1305 (1350 bytes) seal operations in 3001412us (379488.1 ops/sec): 512.3 MB/s Did 220000 ChaCha20-Poly1305 (8192 bytes) seal operations in 3006395us (73177.3 ops/sec): 599.5 MB/s 可以看到，尽管纯软件实现的 ChaCha20 算法已经十分优秀，但跟有 AES-NI 加持的 AES-GCM 比起来还是差距明显。
综上，我们很容易想到「仅针对支持 AES-NI 的终端使用 AES-GCM 算法，否则使用 ChaCha20」无疑是一个非常完美的方案。
BoringSSL
之前文章介绍过，基于 LibreSSL 编译 Nginx，可以轻松地使用 ChaCha20。但问题是一旦配置了 ChaCha20，只要终端支持，无论桌面设备还是移动设备都会使用它。
BoringSSL 是 Google 从 OpenSSL 拉出来的一个独立发展的分支，目前跟 OpenSSL 相比已经有很多不同之处了。BoringSSL 支持了一种名为「等价加密算法组（Equal preference cipher groups）」的配置（ 详情 ），正好可以满足我们这个需求。
基于 BoringSSL 编译 Nginx 之后，可以像下面这样配置 ssl_ciphers ：
ssl_ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]:[ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:DES-CBC3-SHA; 方括号之中的配置就是「等价加密算法组」，用竖线隔开的两种算法，会被自动应用于最合适的场景（支持 AES-NI 优先使用 AES-GCM，否则优先使用 ChaCha20）。最后的 DES-CBC3-SHA 是为了支持 Windows XP 上的 IE8 而加上去的。
下图中，同样是访问本博客，左侧是 Mac Chrome 的截图，右侧是 iPhone Chrome 的截图：
可以看到，只有移动端才使用了 ChaCha20。
值得注意的是，现阶段 BoringSSL 不支持 OCSP Stapling。所以改用 BoringSSL 后，如果在 ssllabs 测试中发现这一项变成 off 不要吃惊。
详细配置步骤
之所有把这部分内容放在最后，是因为折腾起来有点费劲，嫌麻烦的同学可以直接忽略之后所有内容。
以下步骤在我两台系统为 Ubuntu 14.04.3 的 VPS 上都能正常执行。如果你遇到了问题，请留言指出。
首先，获取编译所需的 Nginx 和 BoringSSL 源码，Nginx 从 1.7.4 开始支持 BoringSSL，这里我直接使用最新版：
wget http://nginx.org/download/nginx-1.9.5.tar.gz tar xzf nginx-1.9.5.tar.gz git clone https://boringssl.googlesource.com/boringssl 现在，当前目录下应该有这两个子目录：
boringssl/ nginx-1.9.5/ 确认无误后，还要做一些准备工作：
# 安装编译 BoringSSL 所需的 Golang sudo apt-get install golang # 忽略编译过程中的 Warning（不加这个，编到一半会因为 Warning 太多无法继续） export CFLAGS="-Wno-error" 编译 BoringSSL：
# 进入 BoringSSL 源码根目录 cd boringssl # 创建 build 目录并编译，完成后回到 BoringSSL 源码根目录 mkdir build && cd build && cmake ../ && make && cd ../ # 创建 .openssl 目录，并将库文件和编译后的文件放进去 mkdir -p .openssl/lib && cd .openssl && ln -s ../include . && cd ../ cp build/crypto/libcrypto.a build/ssl/libssl.a .openssl/lib 现在可以编译 Nginx 了：
# 进入 Nginx 源码根目录 cd nginx-1.9.5 # 修改时间，避免 Nginx 再次编译 BoringSSL touch ../boringssl/.openssl/include/openssl/ssl.h # 指定使用 BoringSSL 作为 SSL 库 ./configure --with-openssl=../boringssl --with-http_v2_module --with-http_ssl_module 一切无误后可以开始 make 和 make install 了。这期间可能还会遇到这样一个报错：
'SSL_R_BLOCK_CIPHER_PAD_IS_WRONG' undeclared
这是因为 BoringSSL 删掉了这个变量。找到报错文件中对应的位置，例如：
|| n == SSL_R_BLOCK_CIPHER_PAD_IS_WRONG /* 129 */ 删掉这一行，或者加个判断都可以解决问题：
#ifdef SSL_R_BLOCK_CIPHER_PAD_IS_WRONG || n == SSL_R_BLOCK_CIPHER_PAD_IS_WRONG /* 129 */ #endif 其他应该没什么问题了。 make install 之前记得先停掉 nginx 服务，不然很可能需要手动杀死之前的 nginx 进程。一切妥当后，参考前文修改 ssl_ciphers 并启动服务，搞定收工！
本文链接： https://imququ.com/post/optimize-ssl-ciphers-with-boringssl.html
-- EOF --
于 2015-10-15 11:45:29 发表于「WEB 后端」分类下。
本站部署于「 阿里云 ECS 」。如果你也要购买阿里云服务，可以使用我的九折推荐码 NY1Z0E ，感谢你对本站的支持！
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
