OpenSSL - ChaCha prioritized - Nginx enhancement

[xetorixik@…]

OpenSSL ​supports ChaCha prioritized in their upcoming version.

With this new feature you could not only set ServerPreference (SSL_OP_CIPHER_SERVER_PREFERENCE) but also PrioritizeChaCha (SSL_OP_PRIORITIZE_CHACHA).

Please add OpenSSL PrioritizeChaCha support to Nginx.

"IFF the client has ChaCha first, and server cipher priority is used,
and the new SSL_OP_PRIORITIZE_CHACHA_FOR_MOBILE option is used,
then reprioritize ChaCha above everything else. This way, A matching
ChaCha cipher will be selected if there is a match. If no ChaCha ciphers
match, then the other ciphers are used."

[Maxim Dounin]

So, it's basically allows configuring something like "prefer server ciphers, but not for ChaCha; for ChaCha, prefer client ciphers instead". Funny enough. Simply "prefer client ciphers" might actually be a better option, and this is ​the default.

Just for the record, here is the ​pull request which introduces the option and the related discussion. I completely agree with Viktor Dukhovni that this "feature" looks more like a hack. And I don't think that the same hack should be introduced in nginx. At most, we can consider a generic interface to set various OpenSSL options.

[xetorixik@…]

A "generic interface to set various OpenSSL options" should be fine.
Thanks for the reply.

[Neil Craig]

Hi
I'd really love to see a way to be able to use the -prioritize_chacha flag in nginx, ideally as a runtime (rather than compile time) option.

For the sake of completeness (apologies if you know all this already), it's perhaps worth stating that CHACHA is roughly 3x faster than AES-based suites (see ​https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/#performance) for clients which don't have AES NI instructions in their CPU - so clearly CHACHA is attractive. Also worth noting that CHACHA is significantly slower than AES on platforms which do have AES NI.

We can't use simple (serverside) ciphersuite pref order to use CHACHA as many/most clients running on platforms which do have AES NI instructions in their CPU and they offer CHACHA so if we pref that as #1 on the server side, CHACHA will be used for clients with AES NI and performance suffers.

This means that it's essentially impossible to use CHACHA without a directive or a patch (of which several exist e.g. ​https://github.com/cloudflare/sslconfig/tree/master/patches but trying to use patches long term is obviously not ideal as all those i have tried don't work on current nginx versions). I can't even find a way to pref CHACHA in Lua (via the Openresty module).

So if there is any way we could get a way in nginx runtime (or failing that, compile time) directives to pref CHACHA if it's the top client pref, that'd be amazing. Since OpenSSL has done (what looks to me like) most of the heavy lifting, it seems like it might be quite simple to do (?). I personally would have no preference for a specific (i.e. "prioritise_chacha: <boolean>") or a generic (i.e. "openssl_flags: <string>") directive, it'd just be a great help to be able to use what openSSL provides.

If it would help, i could ask one of my colleagues in engineering if they could create a diff to be (hopefully) merged, though they might need some pointers/help to make sure it's done in an acceptable way).

Cheers
Neil

[Neil Craig]

Sorry to hassle but i'm just wondering if the above changes things at al? It'd be great to hear the thoughts of the nginx folks :-)

[Maxim Dounin]

As already mentioned in the comment:1, most simple solution would be to keep the default value of ssl_prefer_server_ciphers. Trying to configure ciphers preference order on the server side inevitably means that the resulting order will be suboptimal for some clients.

[Steffen Weber]

Patch that enables the SSL_OP_PRIORITIZE_CHACHA flag if "ssl_prefer_server_ciphers" is enabled. Maybe this could be an option for nginx?

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
index 7512913..bae62b7 100644
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -665,7 +665,7 @@ ngx_ssl_ciphers(ngx_conf_t *cf, ngx_ssl_t *ssl, ngx_str_t *ciphers,
     }

     if (prefer_server_ciphers) {
-        SSL_CTX_set_options(ssl->ctx, SSL_OP_CIPHER_SERVER_PREFERENCE);
+        SSL_CTX_set_options(ssl->ctx, SSL_OP_CIPHER_SERVER_PREFERENCE | SSL_OP_PRIORITIZE_CHACHA);
     }

 #if (OPENSSL_VERSION_NUMBER < 0x10100001L && !defined LIBRESSL_VERSION_NUMBER)

Originally posted here: ​https://www.computerbase.de/forum/threads/in-eigener-sache-computerbase-nutzt-tls-1-3-ecdsa-und-lets-encrypt.1829997/page-3#post-21831569

[Steffen Weber]

Alternative: ​https://github.com/kn007/patch/blob/master/nginx_auto_using_PRIORITIZE_CHACHA.patch

[Maxim Dounin]

I'm sceptical about unconditional use of SSL_OP_PRIORITIZE_CHACHA, as this is not what ssl_prefer_server_ciphers is expected to mean.

Note well that if really needed, SSL_OP_PRIORITIZE_CHACHA can be turned on via OpenSSL config, without patching nginx. For example:

openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = PrioritizeChaCha

[Maxim Dounin]

See also #1529 for another example where a generic interface to set various OpenSSL options might be useful.

[Maxim Dounin]

See also #1778.

[Alexey Ivanov]

In BoringSSL we use "equal preference cipher groups":

e.g.:

ssl_ciphers                 '[ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305|ECDHE-RSA-AES128-GCM-SHA256|ECDHE-RSA-CHACHA20-POLY1305]:ECDHE+AES128:RSA+AES128:ECDHE+AES256:RSA+AES256:ECDHE+3DES:RSA+3DES';

[Maxim Dounin]

See also #1942.