My one and only one beef with Rustls is the inability to support some legacy crypto standards that aren't web safe but necessary for replacing OpenSSL in some cases (ie: server to server, database SSL, etc).
The project is the best one for use on the internet with modern SSL standards, however.
More accurately: primitives from the aws-lc library (written in C and assembly, with tests in C++) outperform the OpenSSL and BoringSSL implementations they are based on, on some platforms.
> OpenSSL and its derivatives, widely used across the Internet, have a long history of memory safety vulnerabilities with more being found this year. It's time for the Internet to move away from C-based TLS.
Seems like a cheap shot, considering Rustls's default cryptography is implemented using a fork of OpenSSL's libcrypto.
Of course, there's nothing wrong with writing memory-safe TLS atop C and assembly primitives. But to say that OpenSSL causes memory safety vulnerabilities without being clear that aws-lc-rs uses FFI to call down into AWS-LC, which is based on libcrypto from OpenSSL and BoringSSL seems disingenuous.
A comparison to https://en.wikipedia.org/wiki/LibreSSL would also be nice.
Will RustTLS support ECH? I would like the ability to hide the real server name in the SNI handshake to HAProxy.
'We'd also like to thank Intel for helping with AVX-512 optimizations for aws-lc-rs recently. This was an important part of achieving our performance goals.'
Testing on an intel processor, with frequency scaling disabled, which will adversely affect non AVX-512 more than AVX-512 stuff due to the limited boost available when using this. I'm pretty sure this is a not totally fair comparison, and tuning the box to give your solution an advantage rather than tuning it for each solution to give optimal performance would be more realistic.
However, i'm not knocking it, sounds like a great achievement, and it'll spur the other solutions on to improve their implementations which is a win all round.