Opened 18 months ago

Closed 18 months ago

Last modified 8 weeks ago

#1529 closed task (wontfix)

Could not configure TLS1.3 ciphers in OpenSSL 1.1.1 pre4

Reported by: jinham335908093@… Owned by:
Priority: minor Milestone: 1.13
Component: nginx-module Version: 1.13.x
Keywords: TLS1.3 new openssl api Cc:
uname -a: Linux jintaiyang123.org 4.15.0-13-generic #14-Ubuntu SMP Sat Mar 17 13:44:27 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.13.11 built by gcc 7.3.0 (Ubuntu 7.3.0-16ubuntu2) built with OpenSSL 1.1.1-pre5-dev xx XXX xxxx TLS SNI support enabled configure arguments: --add-module=../ngx_brotli --add-module=../nginx-ct --with-http_v2_module --with-http_ssl_module --with-http_gzip_static_module --add-module=../incubator-pagespeed-ngx-latest-stable --with-openssl=../openssl-test --with-openssl-opt='enable-ec_nistp_64_gcc_128 enable-weak-ssl-ciphers'

Description

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)?

Change History (16)

comment:1 follow-up: Changed 18 months ago by mdounin

  • Cc cc (Ubuntu 7.3.0-16ubuntu2) 7.3.0 Copyright (C) 2017 Free Software Foundation Inc. This is free software see the source for copying conditions. There NO warranty not even MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. removed
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:2 Changed 18 months ago by mdounin

See also #1533.

comment:3 Changed 18 months ago by 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.

comment:4 Changed 18 months ago by mdounin

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.

comment:5 follow-up: Changed 14 months ago by 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

comment:6 in reply to: ↑ 5 ; follow-up: Changed 14 months ago by 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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 14 months ago by 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?

comment:8 in reply to: ↑ 7 Changed 14 months ago by mdounin

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.

comment:9 Changed 12 months ago by 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.)

comment:10 in reply to: ↑ 1 Changed 12 months ago by https://stackoverflow.com/users/8644423/vin%c3%adcius-lima

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.

comment:11 Changed 12 months ago by mdounin

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.

comment:12 Changed 12 months ago by mdounin

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.

comment:13 Changed 12 months ago by mdounin

See also #1670.

comment:14 Changed 10 months ago by GreenReaper@…

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.

In my case I wished to prioritize 128-bit AES over 256-bit AES and CHACHA20, so I used:
Ciphersuites = TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

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.

Version 2, edited 10 months ago by GreenReaper@… (previous) (next) (diff)

comment:15 Changed 8 months ago by pluknet

See also #1734.

comment:16 Changed 8 weeks ago by pluknet

See also #1839.

Note: See TracTickets for help on using tickets.