4 ms·
> 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
by favorited 2y ago
> 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.
- tptacek 2y agoMost OpenSSL vulnerabilities are in TLS itself and in format processing (X.509, PKCS), and the vulnerabilities that do implicate libcrypto tend not to implicate constructions Rustls would use.
- akira2501 2y ago> tend not to implicate constructions Rustls would use. Ah, so if it's just a question of identifying and using the "good" C code, it really makes me wonder what Rust is actually adding here.
- tptacek 2y agoIt's replacing the bad C code. Not all C code is equivalently easy or difficult to write.
- mkj 2y agoMaybe the good C code isn't C code at all, it's actual perl scripts! https://github.com/dot-asm/cryptogams https://github.com/dot-asm/cryptogams
- toast0 2y agoThe ciphers and hashes from OpenSSL have almost always been good C code. I'm sure there have been issues with variable runtimes leaking information, but memory safety won't be a cipher problem. The protocol code, and the x.509 code from OpenSSL hasn't always been great. Rust providing memory protection on that is a nice thing. There's certainly a question of how that makes for significantly more performance; handshake performance is usually dominated by crypto performance, and the same for data transfer... so if the crypto is coming from the same library, it's unexpected to see such a big change (10%+ in most graphs by my eye?) Seems like it would be interesting to take one of these and really dig into it. That said, I know OpenSSL 3 was having some performance issues in some applications because of new locking behaviors; I don't know if BoringSSL took those or not.
- mannyv 2y agoAre the improvements due to AWS-LC ie: what about a test of that without the rust wrapper?
- adzm 2y agoFrom what I can tell most if not all of the security issues that have plagued OpenSSL etc have been with the code around the cryptographic primitives implementing the protocols, rather than the primitives themselves, which generally are very self-contained. That said, the performance speaks for itself here.
- wbl 2y agoCryptography functions are much safer than parsers or complex protocol logic.
- quadhome 2y agoAWS-LC was forked from libcrypto, but it’s also (partially) been formally verified. Comparing it to OpenSSL is a bit much.
- favorited 2y agolibcrypto is core component of the OpenSSL toolkit, and its source tree is part of the OpenSSL repo: https://github.com/openssl/openssl/tree/master/crypto https://github.com/openssl/openssl/tree/master/crypto
- selfmodruntime 2y agoPrefix Note: I am a Rust Nerd This Problem exists all the way down in Rust‘s crypto libraries. OpenSSL just uses bindings, Ring uses BoringSSL which is just again C under the hood. The only real Rust-only crypto project is RustCrypto, but they got a bit too clever with traits and generics. Also, the project is pretty undocumented.
- jrpelkonen 2y agoIt seems that RustCrypto performance is not competitive according to these benchmarks: https://jbp.io/graviola/ https://jbp.io/graviola/
- ahoka 2y agoTLS != ciphers