Add support for equal preference cipher groups

[kaze87]

ChaCha20+Poly1305 should only be used if it is the top client's cipher.

AES with AES-NI outperforms ChaCha20 (1350 bytes benchmark):

AES-128-GCM:      1059.9 MB/s
AES-256-GCM:       941.1 MB/s
ChaCha20-Poly1305: 512.3 MB/s

Source:
https://www.zeitgeist.se/2014/08/23/optimize-aes-and-chacha20-usage-with-boringssl/

=> AES with AES-NI is ~twice as fast, thus should be the preferred cipher suite.

Maybe it is a good idea to introduce equal preference groups, like BoringSSL recently added. [ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE-ECDSA-AES256-GCM-SHA384:…

Also see cloudflare's openssl patch: https://github.com/cloudflare/sslconfig/blob/master/patches/openssl__chacha20_poly1305_cf.patch#L4191

[4a6f656c]

Unless you use SSL_OP_CIPHER_SERVER_PREFERENCE, the first matching cipher based on the client's preference should be used - are you suggesting this is not the case?

That said, it is currently true that a LibreSSL client will prefer ChaCha20-Poly1305 to any other cipher suite.

[kaze87]

When not explicitly using SSL_OP_CIPHER_SERVER_PREFERENCE, the client decides which of server's supported cipher suites he wants to use. Generally speaking, it's a very bad idea to leave that task to the client. We assume that the server administrator will be much faster to react when it comes to new flaws in cipher suites. That's why the first thing you want/have to do if you set up a secure web server is to enable SSL_OP_CIPHER_SERVER_PREFERENCE. Also see Mitigating the BEAST attack on TLS: http://www.net-security.org/article.php?id=1638

I really like BoringSSL's approach to equally group ciphers. A server should be able to let a client decide which cipher suite to use iff the server lists multiple ciphers as equally secure.

Are there plans to support group-like cipherlists in the near future?

[cypres]

CloudFlares approach is a hack, I like the BoringSSL equal-preference groups approach. I'm crossing fingers that LibreSSL picks this up too, if so then I can stop using BoringSSL :)

It's described in more detail here: include/openssl/ssl.h#638

Rationale and blog posts: https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html https://www.zeitgeist.se/2014/08/23/optimize-aes-and-chacha20-usage-with-boringssl/

[4a6f656c]

Since r1.81 of ssl_ciph.c, AES has been preferred over Chacha20+Poly1305, if the host has hardware support for AES. That said, we're still looking at supporting equal preference groups.

[leonklingele]

:+1: Also see this commit: https://github.com/libressl-portable/openbsd/commit/1958d57249e8fd9027f030c8db0692d7eca8b4b7 Anyway, imo this is just a hack until we get support for equal-preference ciphersuite groups.

I've just recompiled nginx + libressl (r 1.83 of ssl_ciph.c), but my AES-NI capable server still uses CHACHA20_POLY1305.. What am I doing wrong? EDIT: Turns out this change only prefers AES suites in the output of openssl ciphers. nginx' ssl_ciphers directive overwrites this preference, of course. Stupid me.

[vyv03354]

We assume that the server administrator will be much faster to react when it comes to new flaws in cipher suites. That's why the first thing you want/have to do if you set up a secure web server is to enable SSL_OP_CIPHER_SERVER_PREFERENCE.

History disproves the hypothesis; See below.

Also see Mitigating the BEAST attack on TLS: http://www.net-security.org/article.php?id=1638

Then many lazy server administrators left their servers RC4-preferred or even RC4-only even after 1/n-1 record splitting mitigated the BEAST and many attacks to RC4 are reported.

[chinkung]

Do we have any update or ETA on this feature ?

[jellemdekker]

I'd love to know the status of this as well.

[leonklingele]

btw: nginx now supports setting arbitrary SSL_CONF_cmd options, e.g. PrioritizeChaCha. See https://github.com/nginx/nginx/commit/ac9c1622822260f81edcf582887a5f0271c2c4c6

[HLFH]

btw: nginx now supports setting arbitrary SSL_CONF_cmd options, e.g. PrioritizeChaCha. See nginx/nginx@ac9c162

Great! Should be released on 27/10/2020 with nginx 1.19.4 release: https://trac.nginx.org/nginx/milestone/nginx-1.19.4.