openssl: OpenSSL 1.1.0 s_server doesn't work with secp384r1 and secp521r1

As the title says, 1.1.0 s_server is not working with secp384r1 and secp521r1, but at 1.0.2a it is ok. I tried OpenSSL 1.1.0 and OpenSSL 1.0.2a with curves from ecparam -list_curves and these 2 curves differs.

OpenSSL 1.0.2a s_client and s_server - both curves are ok

OpenSSL 1.1.0 s_server:

error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared
cipher:ssl/statem/statem_srvr.c:1422

then OpenSSL 1.1.0 s_client:

error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake
failure:ssl/record/rec_layer_s3.c:1382:SSL alert number 40

Keys and certs generated by:

openssl ecparam -genkey -name prime256v1 -out ca.key
openssl req -x509 -batch -new -key ca.key -out ca.cert -subj '/CN=ca'

for t in server client; do
          openssl ecparam -genkey -name prime256v1 -out $t.key
          openssl req -batch -new -key $t.key -out $t.csr -subj "/CN=$t"
          openssl x509 -req -CAkey ca.key -CA ca.cert -CAcreateserial
-in $t.csr -out $t.cert
          rm -f $t.csr
done

s_server command:

openssl s_server -key server.key -cert server.cert -CAfile ca.cert
-sigalgs ECDSA+SHA384:ECDSA+SHA256 -Verify 1 -named_curve secp384r1

s_client command:

openssl s_client -connect localhost:4433 -cert client.cert -key
client.key -CAfile ca.cert -tls1_2 -sigalgs ECDSA+SHA384:ECDSA+SHA256

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 6
Comments: 16 (5 by maintainers)

Commits related to this issue

Tolerate a Certificate using a non-supported group on server side If a server has been configured to use an ECDSA certificate, we should allow it regardless of whether the server's own supported grou... — committed to mattcaswell/openssl by mattcaswell 6 years ago
Tolerate a Certificate using a non-supported group on server side If a server has been configured to use an ECDSA certificate, we should allow it regardless of whether the server's own supported grou... — committed to mattcaswell/openssl by mattcaswell 6 years ago
Tolerate a Certificate using a non-supported group on server side If a server has been configured to use an ECDSA certificate, we should allow it regardless of whether the server's own supported grou... — committed to openssl/openssl by mattcaswell 6 years ago

Most upvoted comments

Yes, @vdukhovni independently discovered this same issue recently. The problem is that in 1.1.0 the supported curves affect both ECDHE and ECDSA. They should really be independent of each other. This means you can’t use a different curve in your ECDSA certificate to the curve used for ECDHE.

Ping @vdukhovni and @snhenson, how do we progress this?

mattcaswell on Dec 6, 2016

The correct approach is outlined in the TLS 1.3 draft. We need to choose a certificate that matches a client supported signature algorithm if possible, but otherwise go with some default certificate.

What this means for OpenSSL is that the server’s ECDHE curve list SHOULD NOT be used to constrain the server’s certificate. While we must choose the ECDHE curve based on the intersection of the server and client supported curves list, the server certificate need only appear on the client curve list, and the server curve list should be ignored in this context. In addition if the only EC certificate uses a curve that is not on the client’s supported curves list, and we have no alternative (RSA or DSA) certificate to choose from, we just go with the certificate we have, and leave its ultimate suitability up to the client.

vdukhovni on Jan 8, 2017

Sure, so we may also need to fine-tune 1.0.2 at some point, with the 1.1.0 situation being a bit more “urgent” as it is not backwards-compatible. Are you willing to take this on, or will it have to wait for me to find the time?

vdukhovni on Jan 8, 2017