ssl_ecdh_curve not honored in server block

[Darkudorus@…]

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.

[Maxim Dounin]

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.

[Darkudorus@…]

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.

[Maxim Dounin]

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.

[Darkudorus@…]

Okay, thank you! ​https://github.com/openssl/openssl/issues/1652

[Kouli]

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.

[Maxim Dounin]

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.