I've noticed to send ECC extensions requires not only --enable-ecc but --enable-supportedcurves and wolfSSL_CTX_UseSupportedCurve. I had only done --enable-ecc and recently tried to connect to a go server using wolfSSL and it failed because the only ciphersuites the server had in common were ECDHE, and go server won't select ECDHE unless both curve and point extensions are sent by the client.
RFC 4492 in section 4 says "A client that proposes ECC cipher suites may choose not to include these extensions. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5." I've proposed a change in go server to address that, however I think you may want to consider enabling ECC extensions when ECC ciphers are sent, otherwise the server could pick a curve that though allowed by the RFC is not supported by wolfSSL and there could still be an error. Also I think the burden of setting some default supported curves should be on the library.
I think a way to accomplish this would be if --enable-ecc then that should imply --enable-supportedcurves during build, and during runtime if the user does not call wolfSSL_CTX_UseSupportedCurve and wolfSSL is going to send ECDHE in the ClientHello it should include some default list of curves and points that are safe and supported, similar to what OpenSSL does.
The text was updated successfully, but these errors were encountered:
Thanks for the ideas and suggestions. For portability reasons, enabling TLS extensions by default on all platforms may not be the best choice, but it may make sense on standard desktop environments. We'll put this on our list to think over.
If supported curves has been enabled, having wolfSSL send a default list of curves sounds like a good idea (unless explicitly set with wolfSSL_CTX_UseSupportedCurve()). We'll add this to our desired feature list.
To remedy this as much as possible for us I've added support for the ECC curves extension, curl/curl@7921628
I don't see a way to send the the format points extension though so in a build of wolfSSL without static ciphers enabled I don't believe it will be possible to connect to a go server. Please consider adding missing format point extension as a related issue. Thanks
I've noticed to send ECC extensions requires not only
--enable-ecc
but--enable-supportedcurves
andwolfSSL_CTX_UseSupportedCurve
. I had only done--enable-ecc
and recently tried to connect to a go server using wolfSSL and it failed because the only ciphersuites the server had in common were ECDHE, and go server won't select ECDHE unless both curve and point extensions are sent by the client.RFC 4492 in section 4 says "A client that proposes ECC cipher suites may choose not to include these extensions. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5." I've proposed a change in go server to address that, however I think you may want to consider enabling ECC extensions when ECC ciphers are sent, otherwise the server could pick a curve that though allowed by the RFC is not supported by wolfSSL and there could still be an error. Also I think the burden of setting some default supported curves should be on the library.
I think a way to accomplish this would be if
--enable-ecc
then that should imply--enable-supportedcurves
during build, and during runtime if the user does not callwolfSSL_CTX_UseSupportedCurve
and wolfSSL is going to send ECDHE in the ClientHello it should include some default list of curves and points that are safe and supported, similar to what OpenSSL does.The text was updated successfully, but these errors were encountered: