3 ms·
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 B
by gspr 8mo ago
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 8mo agoFrom 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 8mo agoMy 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).