Could not configure TLS1.3 ciphers in OpenSSL 1.1.1 pre4

[jinham335908093@…]

In OpenSSL 1.1.1 pre4 and newer,they add an new api (​https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html) to configure TLS1.3-Only Cipher,so the 'ssl_cipher' in nginx couldn't configure ciphers in TLS1.3 with OpenSSL-1.1.1-pre5. So does nginx have some plans to configure TLS1.3-Only ciphers in OpenSSL 1.1.1 and newer(such as like apache, they will add new option SSLCipherSuiteV1_3)?

[Maxim Dounin]

Just for the record, this is a recent change in OpenSSL, see rationale in the commit log and the associated pull request here:

​https://github.com/openssl/openssl/commit/f865b08143b453962ad4afccd69e698d13c60f77
​https://github.com/openssl/openssl/pull/5392

Given that this is positioned mostly as a band-aid to resolve an immediate problem with accidentally disabling TLS 1.3 ciphers, and OpenSSL developers seems to disagree on the long-term approach, I don't think that nginx should add support for this interface before the long-term approach is clear.

[Maxim Dounin]

See also #1533.

[jinham335908093@…]

As #1533 one of the developers of OpenSSL
said it will be in OpenSSL 1.1.1 stable, so I think fix it is necessary.

[Maxim Dounin]

There are no doubts that this will be in OpenSSL 1.1.1. The question is - what they are going to use in the future. For now, solution to configure ciphers as implemented in OpenSSL 1.1.1-dev looks highly inconsistent, and it is not clear what they are going to do next. Once there will be a clear and consistent long-term approach available, we'll consider what to do with this.

[jinham335908093@…]

Now in OpenSSL's wiki ​https://wiki.openssl.org/index.php/TLS1.3
They actually using a new option to configure TLS1.3 ciphers

[Maxim Dounin]

Replying to jinham335908093@…:

Now in OpenSSL's wiki ​https://wiki.openssl.org/index.php/TLS1.3
They actually using a new option to configure TLS1.3 ciphers

This part is my favorite:

Note that all of the above applies to the "ciphers" command line application as well. This can sometimes lead to surprising results.

[jinham335908093@…]

Replying to mdounin:

Replying to jinham335908093@…:

Now in OpenSSL's wiki ​https://wiki.openssl.org/index.php/TLS1.3
They actually using a new option to configure TLS1.3 ciphers

This part is my favorite:

Note that all of the above applies to the "ciphers" command line application as well. This can sometimes lead to surprising results.

​https://wiki.openssl.org/index.php/TLS1.3#Ciphersuites
It's clearly that they are using a new option to configure TLS1.3-ONLY ciphers now. So would anyone to add the support?

[Maxim Dounin]

Replying to jinham335908093@…:

It's clearly that they are using a new option to configure TLS1.3-ONLY ciphers now. So would anyone to add the support?

It is clear that this approach leads to "surprising results", and this was clear since the introduction of this approach. The long-term approach is still not clear, so see comment:1.

[Steffen Weber]

I just want to kindly ask whether nginx would consider adding a new option to configure TLS 1.3 ciphers now that OpenSSL 1.1.1 final has been released. There currently seems to be no way to change the order/priority of TLS 1.3 ciphers in nginx.

(I've heard that, for performance reasons, it could be advisable to prioritize TLS_AES_128_GCM_SHA256 over TLS_AES_256_GCM_SHA384.)

[topdebg]

Replying to mdounin:

Given that this is positioned mostly as a band-aid to resolve an immediate problem with accidentally disabling TLS 1.3 ciphers, and OpenSSL developers seems to disagree on the long-term approach, I don't think that nginx should add support for this interface before the long-term approach is clear.

Reading ​PR and the ​issue it fixes I didn't find indication that the current approach is just a "band-aid". And the "surprising results" it's not an error, just something that it's not expected when you don't set any cipher for TLSv1.3.
Also ​OpenSSL 1.1.1 it's a Long Term Support (LTS) version so I don't think this is a wontfix.

Maybe NGINX could keep only one directive (ssl_ciphers) and choose what to do if there is no specified TLSv1.3 ciphers.

[Maxim Dounin]

I didn't find indication that the current approach is just a "band-aid"

You may want to take a look at ​this comment by Viktor Dukhovni and the following discussion.

And the "surprising results" it's not an error, just something that it's not expected when you don't set any cipher for TLSv1.3

Yes, sure, this is a documented feature. It doesn't make it better though.

Maybe NGINX could keep only one directive (ssl_ciphers) and choose what to do if there is no specified TLSv1.3 ciphers.

This is what we are currently considering. It would be much easier to do this in the OpenSSL library though. Or, even better, make sure TLSv1.3 ciphers are properly matched against existing cipher strings, avoiding original issue with empty set of TLSv1.3 ciphers in the first place.

[Maxim Dounin]

Just to make sure it is known to people reading this ticket. Here is how TLSv1.3 ciphers can be configured with OpenSSL 1.1.1 without any nginx support, using the openssl.conf file:

openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Ciphersuites = TLS_CHACHA20_POLY1305_SHA256

See also #1445, which is somewhat related.

[Maxim Dounin]

See also #1670.

[Laurence 'GreenReaper' Parry]

While I sympathize with the desire not to implement an interface which may be superseded, this should be documented for ​ssl_ciphers (and the helpful workaround above noted) so that people don't tear their hair out wondering why their cipher list - accepted without complaint - doesn't work. It currently implies that the output of openssl ciphers can be used in full, which now includes TLS_* suites.

I wished to prioritize 128-bit AES over 256-bit AES and CHACHA20 (except on mobile), so I used:

 Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_CCM_SHA256:TLS_AES_128_CCM_8_SHA256
 Options = ServerPreference,PrioritizeChaCha

It might be useful to set a nginx-specific OpenSSL config file (this was useful for ensuring that TLS 1.2 with compression was used for PostgreSQL, not TLS 1.3), but that is beyond the scope of this ticket.

[Sergey Kandaurov]

See also #1734.

[Sergey Kandaurov]

See also #1839.

[Maxim Dounin]

See also #1878.

[c7hm4r@…]

Replying to Maxim Dounin:

Here is how TLSv1.3 ciphers can be configured with OpenSSL 1.1.1 without any nginx support, using the openssl.conf file:

I could not find any documentation about how to make Nginx use a certain OpenSSL configuration file. On Ubuntu, the header of the file /etc/ssl/openssl.cnf contains:

# OpenSSL example configuration file.
# This is mostly being used for generation of certificate requests.

So I do not have much confidence that OpenSSL reliably applies the options there when used by Nginx as it seems to depend on the environment variable OPENSSL_CONF and I am not sure if it is set by Nginx. I also did not find any hint that this file is used by default by OpenSSL system-widely.

Configuring OpenSSL is maybe not Nginx’ reliability, but some hint in the official documentation would be great.

[bilditup1@…]

So I do not have much confidence that OpenSSL reliably applies the options there when used by Nginx as it seems to depend on the environment variable OPENSSL_CONF and I am not sure if it is set by Nginx. I also did not find any hint that this file is used by default by OpenSSL system-widely.

Configuring OpenSSL is maybe not Nginx’ reliability, but some hint in the official documentation would be great.

OPENSSL_CONF is not, in fact, set, neither by OpenSSL nor by nginx. It's easy enough to set it using your distro's service manager of choice or otherwise by some script. In systemd on Ubuntu, for example, one would want to add this to the Service section of /lib/systemd/system/nginx.service:

Environment=OPENSSL_CONF=/etc/ssl/openssl.cnf

substituting the above path for that of whichever openssl.cnf file you'd like to use (it doesn't *need* to be the one in the 'official' openssl directory). After that, it looks like nginx does in fact respect the values in whatever configuration file you specified above.

And yeah, it would be nice if this information, along with Maxim's and Laurence's example configs above, were made available in some official document, instead of just this old ticket, particularly if an insistence on the jankiness of the current API means that specifying TLS 1.3 ciphersuite order directly in nginx's own configuration files is not in the cards in the foreseeable future. Not trying to be a jerk about it, I understand this is a free product, you are under no obligation, and this configuration information would be for an entirely different package which you don't produce or control, etc. But I bet it would be enormously helpful to many people who, like me, discovered this bug report ages ago, but couldn't figure out how to get these settings to take until very recently.

[Maxim Dounin <mdounin@…>]

In 7729:3bff3f397c05/nginx:

SSL: ssl_conf_command directive.

With the ssl_conf_command directive it is now possible to set
arbitrary OpenSSL configuration parameters as long as nginx is compiled
with OpenSSL 1.0.2 or later. Full list of available configuration
commands can be found in the SSL_CONF_cmd manual page
(​https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html).

In particular, this allows configuring PrioritizeChaCha option
(ticket #1445):

ssl_conf_command Options PrioritizeChaCha;

It can be also used to configure TLSv1.3 ciphers in OpenSSL,
which fails to configure them via the SSL_CTX_set_cipher_list()
interface (ticket #1529):

ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;

Configuration commands are applied after nginx own configuration
for SSL, so they can be used to override anything set by nginx.
Note though that configuring OpenSSL directly with ssl_conf_command
might result in a behaviour nginx does not expect, and should be
done with care.

[Maxim Dounin]

The ssl_conf_command directive was committed. Among other things it can be used to tune TLSv1.3 ciphers in OpenSSL.

Just for the record: in LibreSSL TLSv1.3 ciphers can be tuned using the existing interface to configure ciphers, ssl_ciphers. And in BoringSSL TLSv1.3 ciphers cannot be tuned at all.