Quantcast
Channel: CodeSection,代码区,网络安全 - CodeSec
Viewing all articles
Browse latest Browse all 12749

等价加密算法组并不是 HTTPS 性能调优的利器

0
0

这篇文章是 《https优化必须了解ChaCha20-Poly1305算法》 的延伸。现在我们知道在HTTPS协议中,主流的加密算法是AES-GCM和ChaCha20-Poly1305算法,那么服务器应该优先使用那个算法呢?或者说密码套件协商的规则是什么?

密码套件协商规则

假设台式机客户端(比如浏览器)在进行HTTPS握手的时候,会发送一组本机支持的密码套件(排在第一位的加密算法是AES-GCM,第二位的是ChaCha20-Poly1305);假设移动设备的客户端在进行HTTPS握手的时候,会发送一组本机支持的密码套件(排在第一位的加密算法是ChaCha20-Poly1305,第二位的是AES-GCM),那么服务器和客户端应该协商出那个密码算法呢?

在TLS密码库中(OpenSSL、NSS),协商一致的密码套件实际上是由服务器决定的,比如在Nginx中配置:

#配置(1) ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers on;

其中 ssl_prefer_server_ciphers 指令解释如下:

Specifies that server ciphers should be preferred over client ciphers

也就是说最终协商出的密码套件以服务器配置为准。

如果客户端发送的密码套件同时包含ChaCha20-Poly1305和AES-GCM,而服务器也同时支持这两种算法,那最终选择的密码套件取决于服务器的配置。在上面的配置中,ECDHE-ECDSA-CHACHA20-POLY1305优先级更高,也就是最终会使用ChaCha20-Poly1305算法。

如果 ssl_ciphers 指令对应的算法调换下顺序,比如:

# 配置(2) ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305'; ssl_prefer_server_ciphers on;

那么最终会使用 AES-GCM 算法。

聪明的同学可能会猜到,以上面的配置(1)为例,ECDHE-ECDSA-AES128-GCM-SHA256很有可能永远不会被选择(除非某个客户端不支持 ChaCha20-Poly1305 算法),确实是这样的。

那么为什么密码套件协商要以服务器为准呢?

从安全性考虑,因为如果以客户端密码套件优先级配置为主,那么攻击者可以强迫服务器最终协商出相对不安全的密码套件。

服务器可控性更高,比如说大部分服务器是 intel 芯片,你觉得它愿意使用 ChaCha20-Poly1305 算法吗?

等价加密算法组

等价加密算法组直白的说,就是服务器智能的选择密码套件(以客户端支持的密码套件为主),我们先不考虑等价加密算法组是否有用,先看看它是什么概念。

等价加密算法组(Equal preference cipher groups)是 BoringSSL(从OpenSSL fork出的密码库)提出来的,如果你查看 Cloudflare 推荐的 TLS配置(https://github.com/cloudflare/sslconfig),会发现如下的配置:

ssl_ciphers '[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]:ECDHE+AES128'; ssl_prefer_server_ciphers on;

首先说明的是,如果你在nginx中这样配置,启动nginx的时候会报错的,因为nginx使用的OpenSSL不支持等价加密算法组。cloudFlare现在已经使用了 BoringSSL,所以默认就支持等价加密算法组。

等价加密算法组的配置指令很简单,使用“[]”符号将优先级顺序一样的密码套件配置在一起(多个密码套件用“|”符号分隔)。

一旦如此配置,如果客户端优先发送AES-GCM密码套件,那么最终协商出的密码套件就是AES-GCM;如果客户端优先发送ChaCha20-Poly1305密码套件,那么最终协商出的密码套件就是ChaCha20-Poly1305。

需要注意的是,在这个例子中,[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305] 的配置优先级比 ECDHE+AES128 更高,这说明服务器优先级更高(ssl_prefer_server_ciphers on),这一点需要和等价加密算法组的配置区分。 OpenSSL 支持等价加密算法组

考虑到 OpenSSL 的普及性,那么如何让 OpenSSL 也支持这一特性呢?可以打一个patch。

如果你使用的是 OpenSSL 1.1,那么可以进行下列的配置(仅仅描述openssl打patch):

$ wget "https://gitlab.com/buik/openssl/-/archive/openssl-patch/openssl-openssl-patch.zip" $ unzip openssl-openssl-patch.zip $ tar xvf openssl-1.1.0f.tar.gz $ cd openssl-1.1.0f $ patch -p1 < ../openssl-1.1/OpenSSL1.1f-equal-preference-cipher-groups.patch

如果使用的是 OpenSSL 1.1.1,目前还没有patch支持。

等价加密算法组真的有用?

大家可以思考下,为什么OpenSSL 1.1.1的最新版本还没有支持这特性呢?原因可能有多方面,看上去很不错的一个概念,还能让移动设备使用性能更高的ChaCha20-Poly1305算法,何乐而不为呢?

但实际上目前ChaCha20-Poly1305算法的优势没有想象的大。

1:从客户端考虑

移动设备很多使用 ARM 架构,在 《https优化必须了解ChaCha20-Poly1305算法》 也提到,ChaCha20-Poly1305 算法性能是 AES-GCM 的3倍。

可现在移动设备大部分采用 ARM V8 架构,本身已经支持 AES-NI 加速了(比如 iPhone5s以后手机,或者现在的小米手机,我实际测试了下,优先发送的密码套件是AES-GCM)。

就光这一点,直接可以宣告 ChaCha20-Poly1305 算法可能不会普及,从客户端的角度看,不管是台式机还是移动设备,AES-GCM 足够快了。

2:从服务器考虑

大部分台式机和服务器都使用 intel 架构,支持 AES-NI 指令,使用 AES-GCM 密码套件最合适,如果强制让它使用 ChaCha20-Poly1305 算法,性能反而不高(至少对服务器是这样的)。

我们总说 HTTPS 性能优化,需要仔细考虑是优先优化服务器端还是客户端,还是同时优化,这有个取舍。

总结

综合来说,大家也看到了,其实 ChaCha20-Poly1305 算法并没有那么流行,OpenSSL 目前不支持等价加密算法组也可理解了,不过在下个版本中,OpenSSL 还可能会支持,因为这确实一个很有趣的特性。

对于大部分公司来说,其实HTTPS的优化没有太多的银弹,我们只要老老实实的选择主流的配置即可,比如 Mozilla 建议的配置(https://mozilla.github.io/server-side-tls/ssl-config-generator/),没有必要太折腾;当然对于大型企业来说,尤其是 CDN 厂商来说,将性能优化做到极致是可理解的,当然他们更多的会考虑服务器端的 HTTPS 性能。

我会长期关注HTTPS方面的进展,所有写的文章都不是从 《深入浅出HTTPS:从原理到实战》 搬移的,都是我最新学习的,欢迎大家关注,我的公众号(ID:yudadanwx,虞大胆的叽叽喳喳)。


等价加密算法组并不是 HTTPS 性能调优的利器

Viewing all articles
Browse latest Browse all 12749