Closed multiSnow closed 6 years ago
This is due to the fact that secp521r1 is not one of the default signature algorithms or SIGALGS, which causes the TLS session negotiation to fail (the current defaults are X25519, secp256r1 and secp384r1). Using the -named_curve option on s_server and the -groups option on s_client will allow this key to work:
$ openssl s_server -accept 3443 -cert crt.crt -key key.key -named_curve secp521r1
openssl s_client -state -nbio -CAfile crt.crt -connect localhost:3443 -groups secp521r1
(thanks for the detailed report)
Yes the options does work with openssl s_server and s_client. So what about other programs linked with libssl.so
that also failed with secp521r1 ecc key such as curl, python, ruby, etc...?
And, since secp521r1 is written out of default, is there some way to enable it optionally? or I should simply drop it and treat it as insecure and never trust it anymore?
EC curves can be enabled/disabled via the SSL_set1_groups_list(3) (or SSL_set1_curves_list(3)) API - how this is exposed to the user depends on the application or programming language in question.
I'm not aware of any specific issues with secp521r1, however it is unlikely to provide significant advantages over secp384r1 and secp256r1. In many cases X25519 is going to be preferable (see https://safecurves.cr.yp.to/ for some further reading). Additionally, BoringSSL does not enable secp521r1 by default and Chrome does not support it...
ecc key generated with secp521r1 not works:
server side:
client side exit with 1:
but ecc key generated with secp384r1 works well:
server side:
client side:
libressl-portable git version, configure option: