Setting ssl_ecdh_curve to secp384r1 does not work

Sadaf_N · July 5, 2016, 2:00pm

Hi all,

I was running nginx 1.9.12 on Ubuntu 14.04 built from the source tarball
with these options: --with-ipv6 --with-http_ssl_module
–with-http_v2_module --with-openssl=/openssl-1.0.2g

While switching to a new server, I also wanted to switch to the nginx
Docker container using my existing nginx config.

First, I discovered an issue with missing ALPN support due to an old
OpenSSL version in Debian Jessie (see
ALPN support for HTTP/2 · Issue #76 · nginxinc/docker-nginx · GitHub ). Therefore, I
switched to the Alpine image and discovered another issue.

The issue seems to be related to the ssl_ecdh_curve setting. In my
config I set it to secp384r1. With this setting present clients won’t
connect. This is what curl outputs:

curl -vvvv -k “https://localhost”

Rebuilt URL to: https://localhost/
Trying ::1…
connect to ::1 port 443 failed: Connection refused
Trying 127.0.0.1…
Connected to localhost (127.0.0.1) port 443 (#0)
ALPN, offering h2
ALPN, offering http/1.1
Cipher selection:
ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
successfully set certificate verify locations:
CAfile: /usr/local/etc/openssl/cert.pem
CApath: none
TLSv1.2 (OUT), TLS header, Certificate Status (22):
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS header, Unknown (21):
TLSv1.2 (IN), TLS alert, Server hello (2):
error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert
handshake failure
Closing connection 0
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
alert handshake failure

When I remove ssl_ecdh_curve from my config or set it to auto (which is
the default) everything works fine.

To investigate this issue further I created a virtual machine running
Ubuntu 16.04 and installed the latest nginx from the official package
source: nginx: Linux packages I was able to reproduce
the exact same issue in this virtual machine.

Do you have an idea what’s going on here? Please let me know if you need
any additional information.

Thanks!
Florian

Florian_Reinhart · July 5, 2016, 3:20pm

Hello!

On Tue, Jul 05, 2016 at 02:00:04PM +0200, Florian Reinhart wrote:

curl -vvvv -k “https://localhost”
CApath: none

To investigate this issue further I created a virtual machine running Ubuntu
16.04 and installed the latest nginx from the official package source:
nginx: Linux packages I was able to reproduce the exact same
issue in this virtual machine.

Do you have an idea what’s going on here? Please let me know if you need any
additional information.

It looks like the client doesn’t support the curve you’ve
configured, and non-ECDH ciphers are disabled.

–
Maxim D.
http://nginx.org/

Florian_Reinhart · July 5, 2016, 4:02pm

Hi Maxim!

That’s what I thought. However, all clients can access the nginx server
on the old Ubuntu 14.04 server, which uses the same config,

I tested the following clients on OS X 10.11.5, all failed to connect:

curl, installed from Homebrew: curl 7.49.1 (x86_64-apple-darwin15.5.0)
libcurl/7.49.1 OpenSSL/1.0.2h zlib/1.2.5 nghttp2/1.12.0
Safari 9.1.1 (11601.6.17)
Chrome 51.0.2704.106
Firefox 47.0.1

That’s why I don’t think it is a client issue.

Best,
Florian

Florian_Reinhart · July 5, 2016, 4:40pm

Hello!

On Tue, Jul 05, 2016 at 04:02:21PM +0200, Florian Reinhart wrote:

That’s why I don’t think it is a client issue.

Yes, at least browsers are expected to support secp384r1, so it’s
probably something different.

Which certificate do you use? Is it the same as on the old
server? Such a situation can easily happen if the only
certificate available is ECDSA one and uses, e.g., prime256v1 (not
secp384r1), but only secp384r1 is enabled by the configuration.

Looking into nginx error logs might also somewhat help to diagnose
what goes on here.

–
Maxim D.
http://nginx.org/

Florian_Reinhart · July 5, 2016, 5:02pm

Thanks a lot for your suggestions.

It is the same certificate on both servers and it is indeed a secp256r1
aka prime256v1 certificate. So does this mean, I have to use prime256v1
for ssl_ecdh_curve with this certificate? It’s still strange that it
used to work before…

Here is what the error log says:
2016/07/05 16:57:09 [info] 2525#2525: *115 SSL_do_handshake() failed
(SSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared
cipher) while SSL handshaking, client: 192.168.241.1, server:
0.0.0.0:443

Thanks again!

Florian_Reinhart · July 5, 2016, 8:16pm

Hello!

On Tue, Jul 05, 2016 at 05:02:07PM +0200, Florian Reinhart wrote:

It is the same certificate on both servers and it is indeed a
secp256r1 aka prime256v1 certificate. So does this mean, I have
to use prime256v1 for ssl_ecdh_curve with this certificate? It’s
still strange that it used to work before…

Since version 1.11.0 nginx uses the new SSL_CTX_set1_curves_list()
interface if available to configure supported curves, instead of
previously used EC_KEY_new_by_curve_name()/SSL_CTX_set_tmp_ecdh().
This new interface is generally better as it allows configuring
multiple curves.

I’ve just tested, and it looks like this new interface is also
more strict. With previous interface it was possible to use any
certificate regardless of the ssl_ecdh_curve setting, and that’s
why it worked for you in older versions. The new interface does
not allow to use curves which are not listed at all, including
certificates using these curves.

Solution would be to list all curves you want to use, including
curves used by certificates, e.g.:

ssl_ecdh_curve secp384r1:prime256v1;

Or, better yet, just leave the default (“auto”), it will allow
most common curves as supported by OpenSSL.

–
Maxim D.
http://nginx.org/

Florian_Reinhart · July 6, 2016, 11:33am

Hello,

The following are in auto:

secp256r1
secp521r1
brainpool512r1
brainpoolP384r1
secp384r1
brainpoolP256r1
secp256k1
If not configured with OPENSSL_NO_EC2M
sect571r1
sect571k1
sect409k1
sect409r1
sect283k1
sect283r1
#endif

From OpenSSL source:

github.com

openssl/openssl/blob/OpenSSL_1_0_2-stable/ssl/t1_lib.c#L266


      
              NID_secp521r1,              /* secp521r1 (25) */
              NID_brainpoolP256r1,        /* brainpoolP256r1 (26) */
              NID_brainpoolP384r1,        /* brainpoolP384r1 (27) */
              NID_brainpoolP512r1         /* brainpool512r1 (28) */
          };
          
          
static const unsigned char ecformats_default[] = {
              TLSEXT_ECPOINTFORMAT_uncompressed,
              TLSEXT_ECPOINTFORMAT_ansiX962_compressed_prime,
              TLSEXT_ECPOINTFORMAT_ansiX962_compressed_char2
          };
          
          
/* The client's default curves / the server's 'auto' curves. */
          static const unsigned char eccurves_auto[] = {
              /* Prefer P-256 which has the fastest and most secure implementations. */
              0, 23,                      /* secp256r1 (23) */
              /* Other >= 256-bit prime curves. */
              0, 25,                      /* secp521r1 (25) */
              0, 28,                      /* brainpool512r1 (28) */
              0, 27,                      /* brainpoolP384r1 (27) */
              0, 24,                      /* secp384r1 (24) */

Kurt C.
https://www.x64architecture.com

Florian_Reinhart · July 6, 2016, 9:16am

Hi Maxim!

Thanks for investigating this! I thought ssl_ecdh_curve was only used to
specific curves for ECDHE.

Is there any way to know what curves “auto” will include on my system?

—Florian

Florian_Reinhart · July 6, 2016, 6:08pm

Hello!

On Wed, Jul 06, 2016 at 09:15:59AM +0200, Florian Reinhart wrote:

Is there any way to know what curves “auto” will include on my
system?

This is not currently possible, AFAIK, and depends on the OpenSSL
library used. Here is a short summary for varions OpenSSL version
I’ve previously looked into:

OpenSSL 1.0.2, 1.0.2a: all curves supported, strongest first.
Full list is available via “openssl ecparam -list_curves”.
OpenSSL 1.0.2b … 1.0.2h: limited default list with at least
256 bits, prime256v1 (aka P-256) first. List in OpenSSL 1.0.2g
is as follows:
```
P-256:P-521:brainpoolP512r1:brainpoolP384r1:P-384:brainpoolP256r1:secp256k1:B-571:K-571:K-409:B-409:K-283:B-283
```
Upcoming OpenSSL 1.1.0 uses X25519:P-256:P-521:P-384 (aka
X25519:secp256r1:secp521r1:secp384r1).

–
Maxim D.
http://nginx.org/