Opened 6 years ago
Closed 6 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 smoon4.vl-lomov.ru 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/nginx.pid --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 |
Description
Hello,
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 https://bugs.archlinux.org/task/61871 but seems the problem with openssl-1.1.1b (openssl-1.1.1a works fine).
According to https://www.openssl.org/news/changelog.html#x1
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
applications.
[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
Citing from Arch Linux PR:
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:
https://github.com/openssl/openssl/commit/1c31fe7
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:
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.