#1529 closed task (fixed)
Could not configure TLS1.3 ciphers in OpenSSL 1.1.1 pre4
Reported by: | 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 (22)
follow-up: 10 comment:1 by , 6 years ago
Cc: | removed |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
comment:3 by , 6 years ago
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 by , 6 years ago
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.
follow-up: 6 comment:5 by , 6 years ago
Now in OpenSSL's wiki https://wiki.openssl.org/index.php/TLS1.3
They actually using a new option to configure TLS1.3 ciphers
follow-up: 7 comment:6 by , 6 years ago
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.
follow-up: 8 comment:7 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
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.
follow-up: 18 comment:12 by , 6 years ago
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:14 by , 6 years ago
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.
follow-up: 19 comment:18 by , 5 years ago
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.
comment:19 by , 5 years ago
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, 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 whichever one 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.
comment:21 by , 4 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
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.
comment:22 by , 4 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → 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.