Opened 3 months ago

Closed 3 weeks ago

#2101 closed defect (worksforme)

directive ssl_protocols ignored on Ubuntu Server

Reported by: Anton Demenev Owned by:
Priority: major Milestone:
Component: nginx-core Version: 1.19.x
Keywords: Cc:
uname -a: Linux AAFront 5.4.0-45-generic #49-Ubuntu SMP Wed Aug 26 13:38:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.19.4
built by gcc 9.3.0 (Ubuntu 9.3.0-10ubuntu2)
built with OpenSSL 1.1.1f 31 Mar 2020
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-cc-opt='-g -O2 -fdebug-prefix-map=/data/builder/debuild/nginx-1.19.4/debian/debuild-base/nginx-1.19.4=. -fstack-protector-strong -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fPIC' --with-ld-opt='-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pie'

Description

Hi,
I found, that Nginx ignores ssl_protocols directive and using TLS v1.2.

part of config:

    listen 443 ssl;
    ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA;
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/nginx/ssl/dhparam.pem;
    ssl_session_tickets off;

Size of dhparam is 1024.

Operating system - Ubuntu Server Focal.

Same settings working fine on Centos 7 with nginx 1.19.5

Change History (5)

comment:1 by Maxim Dounin, 3 months ago

Note that ssl_protocols has to be specified in the default server block, see ticket #676 for details.

If you've specified ssl_protocols in the default server block and it still doesn't work, please provide more details. The full configuration as shown by nginx -T should be enough.

Similarly, if the same configuration works for you on one server but not the other one, please provide nginx -T output from both servers.

comment:2 by uwe.h.schindler@…, 3 weeks ago

Hi Maxim,
the same issue happened to me. I have the ssl_protocol directive inside http{ ... }. After update to 1.19.6, I am only connect to my server via TLS 1.2, it's impossible to connect via TLS 1.3.

Looks like this is a regression introduced in 1.19.5 or 1.19.6.

Uwe

comment:3 by uwe.h.schindler@…, 3 weeks ago

I figured out what the problem is. You can have all TLS settings on the main level http {}, but you need at least one valid certificate there, otherwise most settings are not applied correctly.

IMHO, there should be some better handling of settings to prevent such surprises like reported here (at least a warning should be printed on startup):

  • generally on the top-level (inside http {}) one should be able to set all general TLS settings globally (as those make no sense inside server blocks), but leaving out the certificates and certificate chains for stapling
  • certificates should be given in the server {} directives
  • in the default server one should give the new nginx option to close connection, if SNI hostname is not given (using ssl_reject_handshake on;). A certificate in default server block is not needed

With this setup you have a server that is very strict:

  • SNI is required
  • certificates are per virtual server
  • on default server, TLS connections are closed
Last edited 3 weeks ago by uwe.h.schindler@… (previous) (diff)

comment:4 by Maxim Dounin, 3 weeks ago

After update to 1.19.6, I am only connect to my server via TLS 1.2, it's impossible to connect via TLS 1.3.

It looks like you are talking about issue described in #2071. This is an OpenSSL bug which is exposed when using nginx with OpenSSL and ssl_reject_handshake without any certificates set. This bug is already fixed in the OpenSSL sources and the fix is expected to be available in the next OpenSSL version. Till then, consider providing some dummy certificate along with ssl_reject_handshake directive if you want TLSv1.3 to work (a dummy one using variables should be enough, something like ssl_certificate $pid; ssl_certificate_key $pid;).

You can have all TLS settings on the main level http {}, but you need at least one valid certificate there, otherwise most settings are not applied correctly.

That's not the case, you don't need valid certificates at the http{} level. But you need one in the default server block even if you are using ssl_reject_handshake for TLSv1.3 to work, due to the OpenSSL bug.

comment:5 by Maxim Dounin, 3 weeks ago

Resolution: worksforme
Status: newclosed

Feedback timeout, closing this. Most likely the original problem is an attempt to specify ssl_protocols in non-default server block, which is not going to work.

Note: See TracTickets for help on using tickets.