[gspr]

Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".

The state of things sucks :-(

[fulafel]

From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here.

Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc.

They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer protocol serialization semantics, you can't confuse a state machine, you can't have a concurrency bug[1] etc.

C memory safety vulnerabilities arise from trying to handle these dynamic things which rustls fixes.

(Also, there are third party crypto providers implemented in Rust)

[1] from memory safety pov; for side channels rust doesn't have advantages anyway

[gspr]

My point is that the article this thread is attached to starts out with how BoringSSL and AWS-LC won't cut it. And when rustls is suggested as an alternative, it's important to point out that it requires precisely those two (either one of them).