Opened 8 years ago

Closed 7 years ago

#1089 closed defect (wontfix)

ssl_ecdh_curve not honored in server block

Reported by: Darkudorus@… Owned by:
Priority: minor Milestone: 1.11.5
Component: nginx-package Version: 1.11.x
Keywords: ngx_http_ssl_module Cc:
uname -a: Ubuntu 16.04 # Linux hostname.tld 4.4.0-38-generic #57-Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: https://launchpad.net/~nginx/+archive/ubuntu/development # nginx version: nginx/1.11.3
built with OpenSSL 1.0.2g-fips 1 Mar 2016 (running with OpenSSL 1.0.2g 1 Mar 2016)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now' --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 --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-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_mp4_module --with-http_perl_module --with-http_random_index_module --with-http_secure_link_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-mail --with-mail_ssl_module --with-stream --with-stream_ssl_module --with-threads --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/headers-more-nginx-module --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-auth-pam --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-cache-purge --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-development-kit --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-echo --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/ngx-fancyindex --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-http-push --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-lua --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-upload-progress --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/nginx-upstream-fair --add-module=/build/nginx-arw1Xp/nginx-1.11.3/debian/modules/ngx_http_substitutions_filter_module

Description

http {

ssl_ecdh_curve secp521r1;
server {

listen ... ssl http2 default_server;
server_name hostname.tld;

}
server {

listen ... ssl http2;
server_mame public.tld;
ssl_ecdh_curve secp384r1;

}

}

Then all browsers will use secp521r1 for all domains. Even if I remove ssl_ecdh_curve from the http-block, all domains will use secp256r1/prime256v1.

Change History (6)

comment:1 by Maxim Dounin, 8 years ago

Looks like a bug in OpenSSL. It copies curves to the connection from the initial SSL context, and then fails to update curves list when context is changed in the SNI callback. As a result, curves configured in the default server will be used for all connections through a listening socket in question.

I don't see a way to easily fix this from nginx side, as there is no way to extract configured list of curves from an SSL context. And, given that this doesn't look practical, introducing workarounds with intermediate storage unlikely worth the effort. Likely it will be addressed somehow in future versions of OpenSSL.

Note that with OpenSSL 1.0.2+ and nginx 1.11.0+ you can use can configure multiple curves at the same time, e.g.:

ssl_ecdh_curve prime256v1:secp384r1:secp521r1;

This is essentially what ssl_ecdh_curve auth does with recent versions of OpenSSL, allowing clients to select a curve they prefer to use.

Last edited 8 years ago by Maxim Dounin (previous) (diff)

comment:2 by Darkudorus@…, 8 years ago

Do you have connections to the OpenSSL project / the ability to report this to them?
Are you thinking that this problem could still exist in the new OpenSSL 1.1.0 beta?


Actually our SNI vhosts (like public.tld from above) have ssl_ecdh_curve secp521r1:secp384r1;
(Firefox+Safari use P-521, Chrome+Edge use P-384).
I want to enforce P-521 for the default host, under which phpmyadmin, postfixadmin and poweradmin are running.

As long Google don't take back their attempt to weaken security ( https://bugs.chromium.org/p/chromium/issues/detail?id=477623#c2 ), Chrome users are punished by Googles decision (to remove P-521) to not be able to connect to websites with long-term protection.

My plan is to motivate Let's Encrypt to sign P-521 ECDSA certs ( https://github.com/letsencrypt/boulder/issues/2143 ) and I've stopped Mozillas thoughts about to remove it from NSS (https://bugzilla.mozilla.org/show_bug.cgi?id=1128792#c20 + https://bugzilla.mozilla.org/show_bug.cgi?id=1306003 ).

In TLS it's not possible to define cuves for ECDSA and ECDHE seperatly. So if I want to use ECDSA P-384 from Let's Encrypt + ECDHE P-521, I have to set "ssl_ecdh_curve secp521r1:secp384r1;", otherwise it wont work. So i switched back to ECDHE-RSA only with my default host to lock out clients, that don't speak P-521 because they are retarded.
But because of this bug here, it unfortunately currently won't work.

in reply to:  2 comment:3 by Maxim Dounin, 8 years ago

Resolution: wontfix
Status: newclosed

Replying to Darkudorus@…:

Do you have connections to the OpenSSL project / the ability to report this to them?

No.

Are you thinking that this problem could still exist in the new OpenSSL 1.1.0 beta?

Yes.

Closing this, eventually OpenSSL will fix the problem.

comment:4 by Darkudorus@…, 8 years ago

Okay, thank you! I will tell them about this.

Version 0, edited 8 years ago by Darkudorus@… (next)

comment:5 by Kouli, 7 years ago

Resolution: wontfix
Status: closedreopened

Couldn't the ssl_ecdh_curve directive be made applicable in http context only, until OpenSSL fixes the problem, please? Both documentation and code allows it to be applied in server context as well, where it is (confusingly!) ignored.

comment:6 by Maxim Dounin, 7 years ago

Resolution: wontfix
Status: reopenedclosed

The ssl_ecdh_curve directive in the server context make sense regardless of the OpenSSL problem, as it allows configuring different curves in different IP-based servers.

Note: See TracTickets for help on using tickets.