#2190 closed enhancement (duplicate)
Feature request: ssl_prefer_server_ciphers exception option for TLSv1.3?
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | trivial | Milestone: | |
| Component: | nginx-core | Version: | |
| Keywords: | Cc: | ||
| uname -a: | Linux plmgmt1 5.4.0-74-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/1.18.0 (Ubuntu)
built with OpenSSL 1.1.1f 31 Mar 2020 TLS SNI support enabled configure arguments: --with-cc-opt='-g -O2 -fdebug-prefix-map=/build/nginx-5J5hor/nginx-1.18.0=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-compat --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-mail=dynamic --with-mail_ssl_module |
||
Description
Just wondering if it would be useful to implement an exception mechanism for TLSv1.3 as far as ssl_prefer_server_ciphers is concerned.
In practice this would mean that when "ssl_prefer_server_ciphers on" is used, an exception can be made for TLSv1.3. This way, clients that prefer a specific cipher can actually use it (e.g. CHACHA20) when using TLSv1.3 while still maintaining a firm grip on the cipher order of pre-TLSv1.3 protocols.
Change History (3)
comment:1 by , 4 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
comment:2 by , 4 years ago
Thanks for your clear answer. I also prefer to let the client choose when only "strong" ciphers are used by the server. That's also the preferred method as described by Mozilla (https://wiki.mozilla.org/Security/Server_Side_TLS).
Using drwetter's test tool testssl.sh (https://github.com/drwetter/testssl.sh) I get a warning when letting the client decide on TLSv1.2, even when only using ECDHE+AESGCM and CHACHA20 ciphers. As there is no 100% right or wrong (and I think I pretty much know what I'm doing) I always choose to ignore that warning.
The thing that led me to open a ticket is that I noticed that Cloudflare somehow manages to let the client choose the cipher using TLSv1.3, but maintains a server cipher order for TLSv1.2. So I started wondering how they pull that off.
Anyway ... I think it's time for me to do some tests using the ssl_conf_command and some tests with only TLSv1.3 enabled.
comment:3 by , 4 years ago
The thing that led me to open a ticket is that I noticed that Cloudflare somehow manages to let the client choose the cipher using TLSv1.3, but maintains a server cipher order for TLSv1.2. So I started wondering how they pull that off.
This means that they are using BoringSSL and ssl_prefer_server_ciphers on;. As mentioned above, BoringSSL simply ignores cipher preference settings for TLSv1.3.
Cipher preference is not something nginx controls: rather, it provides the SSL library with ciphers string, and appropriate options. Depending on the library you use, options may be different: for example, OpenSSL provides hacks to prefer ChaCha20, and BoringSSL simply ignores cipher preference for TLSv1.3 and uses ChaCha20 automatically if preferred by the client (and also provides equal preference cipher groups).
Given your practical considerations, closing this as a duplicate of #1445. The ssl_conf_command directive introduced in nginx 1.19.4 can be used to configure appropriate OpenSSL option.
Note well that a better solution might be to avoid using
ssl_prefer_server_ciphersand instead prefer client ciphers, which is the default.