Skip to content

ClientHello sends ECC ciphers without extensions #366

@jay

Description

@jay

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions