Opened 2 years ago

Closed 2 years ago

#1734 closed defect (wontfix)

nginx failed to work with openssl-1.1.1b

Reported by: Vladimir Owned by:
Priority: critical Milestone: nginx-1.15
Component: nginx-core Version: 1.15.x
Keywords: openssl-1.1.1b Cc:
uname -a: Linux 4.20.12-4-ck-sandybridge #1 SMP PREEMPT Sat Feb 23 15:14:09 EST 2019 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.15.9
built with OpenSSL 1.1.1a 20 Nov 2018
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/ --lock-path=/run/lock/nginx.lock --user=http --group=http --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-cc-opt='-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now --with-compat --with-debug --with-file-aio --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_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-pcre-jit --with-stream --with-stream_geoip_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads


I'm using Archlinux x86_64. Today I updated nginx (nginx-mainline) to version 1.15.9 and openssl to version 1.1.1b and after that nginx cannot start.

I filled distribution bug report but seems the problem with openssl-1.1.1b (openssl-1.1.1a works fine).

According to

Change the info callback signals for the start and end of a post-handshake
message exchange in TLSv1.3. In 1.1.1/1.1.1a we used SSL_CB_HANDSHAKE_START
and SSL_CB_HANDSHAKE_DONE. Experience has shown that many applications get
confused by this and assume that a TLSv1.2 renegotiation has started. This
can break KeyUpdate handling. Instead we no longer signal the start and end
of a post handshake message exchange (although the messages themselves are
still signalled). This could break some applications that were expecting
the old signals. However without this KeyUpdate is not usable for many
[Matt Caswell]

the change between openssl-1.1.1a and openssl-1.1.1b is intentional and seems that breaks nginx.

With openssl-1.1.1b nginx fails with message:

systemd[1]: Starting A high performance web server and a reverse proxy server...
nginx[9256]: 2019/02/27 08:00:25 [emerg] 9256#9256: SSL_CTX_set_cipher_list("TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384") failed (SSL: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match)
systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
systemd[1]: nginx.service: Failed with result 'exit-code'.
systemd[1]: Failed to start A high performance web server and a reverse proxy server.
systemd[1]: nginx.service: Consumed 0 CPU time.

P.S. I tried to create ticket earlier but seems do something wrong because I don't see it in any ticket list.

Vladimir Lomov

Change History (1)

comment:1 by Sergey Kandaurov, 2 years ago

Resolution: wontfix
Status: newclosed

Citing from Arch Linux PR:

Additional info:
* nginx-mainline 1.15.8/1.15.9, openssl-1.1.1a/openssl-1.1.1b
* part of nginx configuration (works fine with openssl-1.1.1a):

ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ecdh_curve prime256v1:secp384r1;
ssl_ciphers TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;

I have nothing to say more than what's commented in the cited bug report.
To reiterate: the OpenSSL behaviour was changed in this commit:

Now SSL_CTX_set_cipher_list() ignores TLSv1.3 ciphersuites (which seems to be as originally intended) and that makes the passed in ssl_ciphers list empty which leads to the above error.
Note well, that the previous OpenSSL behaviour with such a bogus configuration resulted in:

  • a permanent runtime error for TLSv<=1.2 due to empty ciphers.
  • TLSv1.3 ciphers set in the directive actually ignored

Now the error is logged at configuration time, instead. That's a win.

We don't have in plans to support SSL_CTX_set_ciphersuites() API, see comment:1:ticket:1529 for the detailed explanation.

Note: See TracTickets for help on using tickets.