Ladies and gentlemen, it’s story time!!
Once upon a time, there was a network administrator that only wanted to use the strongest NIST-approved ECC encryption available within the TLS 1.3 protocol. They picked ECDHE over the secp521r1 curve. When they went to code their application, they wanted the best TLS library available so they naturally picked wolfssl.
In order to let their peers know that they wanted to use ECDHE over the secp521r1 curve with TLS 1.3, they used the wolfSSL_UseKeyShare() API during the setup of the connection. With this addition they thought they were done. Like any good software developer, they then tested their application against many servers and found that it worked as expected. Happy with the results, our security conscious network administrator began using their new application.
A little while later, during a network security audit, the consultant found that the application was on some occasions using ECDHE over the secp256r1 curve!! Flabbergasted, the network administrator demanded proof and the consultant showed him the wireshark transcripts. Low and behold, the transcripts showed that the server had sent a HelloRetryRequest handshake message requesting secp256r1. This was because the SupportedGroups extension in the ClientHello had advertised support for secp256r1 and that was the only curve that this particular server supported.
In the end, the solution was simple. Our network administrator called wolfSSL_set_groups() specifying only secp521r1. The next time he connected to the offending server, it simply refused the connection. Then our administrator upgraded that server to support secp521r1. Our hero and their application and servers lived happily ever after.
– The End –
Note this parable does not constitute a bug nor vulnerability in the wolfssl library. What happened was exactly how TLS 1.3 is supposed to work. This is a case of unintended consequences due to insufficient configuration.
Another possible more bullet proof solution is to compile out support for weaker ECC curves during the configuration of the wolfssl library.
This parable is especially relevant in the era of post-quantum cryptography. If you are trying to thwart the “harvest now, decrypt later” threat model and you are willing to sacrifice some interoperability, then you do not want to advertise support for conventional algorithms.
If you have questions about any of the above, please contact us facts@wolfSSL.com or call us +1 425 245 8247.
Download wolfSSL Now