-
Notifications
You must be signed in to change notification settings - Fork 925
Description
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.