]> git.kaiwu.me - nginx.git/commit
SSL: logging level of "no suitable key share".
authorMaxim Dounin <mdounin@mdounin.ru>
Tue, 25 Sep 2018 10:59:53 +0000 (13:59 +0300)
committerMaxim Dounin <mdounin@mdounin.ru>
Tue, 25 Sep 2018 10:59:53 +0000 (13:59 +0300)
commit31ef0c47ca676c6640dc535fd5720a831b4c046c
treecd0511ae6f442f71996e59547af6f10ae7dd2f8c
parent1065455289d72b140f9e63a420b531eaae2d4039
SSL: logging level of "no suitable key share".

The "no suitable key share" errors are reported by OpenSSL 1.1.1 when
using TLSv1.3 if there are no shared groups (that is, elliptic curves).
In particular, it is easy enough to trigger by using only a single
curve in ssl_ecdh_curve:

    ssl_ecdh_curve secp384r1;

and using a different curve in the client:

    openssl s_client -connect 127.0.0.1:443 -curves prime256v1

On the client side it is seen as "sslv3 alert handshake failure",
"SSL alert number 40":

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

It can be also triggered with default ssl_ecdh_curve by using a curve
which is not in the default list (X25519, prime256v1, X448, secp521r1,
secp384r1):

    openssl s_client -connect 127.0.0.1:8443 -curves brainpoolP512r1

Given that many clients hardcode prime256v1, these errors might become
a common problem with TLSv1.3 if ssl_ecdh_curve is redefined.  Previously
this resulted in not using ECDH with such clients, but with TLSv1.3 it
is no longer possible and will result in a handshake failure.

The SSL_R_NO_SHARED_GROUP error is what BoringSSL returns in the same
situation.

Seen at:

https://serverfault.com/questions/932102/nginx-ssl-handshake-error-no-suitable-key-share
src/event/ngx_event_openssl.c