使用 BoringSSL 优化 HTTPS 加密算法选择

前不久,一位朋友在我博客评论中,问到:类似于 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):

可以看到,尽管纯软件实现的 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:

方括号之中的配置就是「等价加密算法组」,用竖线隔开的两种算法,会被自动应用于最合适的场景(支持 AES-NI 优先使用 AES-GCM,否则优先使用 ChaCha20)。最后的 DES-CBC3-SHA 是为了支持 Windows XP 上的 IE8 而加上去的。

下图中,同样是访问本博客,左侧是 Mac Chrome 的截图,右侧是 iPhone Chrome 的截图:

可以看到,只有移动端才使用了 ChaCha20。

这里简单介绍一下「等价加密算法组」的原理:我们知道客户端建立 TLS 连接时,在发送的 Client Hello 中会带上自己支持的加密算法,供服务端从中挑选。由于老旧客户端会支持一些不安全的加密算法,为了提高传输安全,通常会在服务端指定一个可用算法列表,最终使用的加密类型取决于二者的交集,并按服务端优先级取第一个;如果没有交集,直接终止会话。在 Nginx 中这个功能通过将 ssl_prefer_server_ciphers 设置为 on 开启。

那么问题来了,对于同时支持 AES-GCM 和 ChaCha20 的 Chrome 来说,服务端列表无论把哪个放前面都会导致另外一个完全没机会被选中。而「等价加密算法组」的意义在于,等价组内的算法具有相同优先级。这样,客户端可以把想要优先使用的加密算法放在前面。举例说明二者的区别(开启 ssl_prefer_server_ciphers 条件下):

  • 不支持等价组时,如果服务端列表是:A、B、C,浏览器 1 支持:A、B,最终使用 A;浏览器 2 支持 B、A,最终使用 A,浏览器 3 支持 C、A,最终使用 A;
  • 支持等价组时,如果服务端列表是:[A|B]、C,浏览器 1 支持:A、B,最终使用 A;浏览器 2 支持 B、A,最终使用 B,浏览器 3 支持 C、A,最终使用 A;

可以看到,开启 ssl_prefer_server_ciphers 可以让会话使用最安全的加密算法(前提是服务端配置正确),而「等价加密算法组」还可以让浏览器有局部调整的权限。

补充一下通过 Mac Chrome 和 iPhone Chrome 分别访问我的博客发送的加密算法列表(使用 wireshark 抓包,在 Client Hello 握手中可获得):

可以看到,Chrome 浏览器确实是会在不同平台上发送不同顺序的算法列表,只要服务端配置了「等价加密算法组」就可以实现本文所描述的功能。

最后提醒大家:现阶段 BoringSSL 不支持 OCSP Stapling。改用 BoringSSL 后,如果在 ssllabs 测试中发现这一项变成 off 不要吃惊。

详细配置步骤

之所以把这部分内容放在最后,是因为折腾起来有点费劲,嫌麻烦的同学可以直接忽略之后所有内容。

以下步骤在我两台系统为 Ubuntu 14.04.3 的 VPS 上都能正常执行。如果你遇到了问题,请留言指出。

首先,获取编译所需的 Nginx 和 BoringSSL 源码,Nginx 从 1.7.4 开始支持 BoringSSL,这里我直接使用最新版:

现在,当前目录下应该有这两个子目录:

确认无误后,还要做一些准备工作:

编译 BoringSSL:

现在可以编译 Nginx 了:

touch 后可以开始 make 和 make install 了。这期间可能还会遇到这样一个报错:

这是因为 BoringSSL 删掉了这个变量。找到报错文件 src/event/ngx_event_openssl.c 中对应的位置:

删掉这一行,或者加个判断都可以解决问题:

其他应该没什么问题了。make install 之前记得先停掉 nginx 服务,不然很可能需要手动杀死之前的 nginx 进程。一切妥当后,参考前文修改 ssl_ciphers 并启动服务,搞定收工!

本文链接:https://imququ.com/post/optimize-ssl-ciphers-with-boringssl.html参与评论
–EOF–

2 3 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部