]> 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)
commitacc13eb8c542fd2c8d85809050adde664a5d175d
tree7cfe860371014b0ff4a1c30f16ac508f5eb89f6a
parentb540af619bb77e522dc435fa7872674f56f0883a
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