6 ms·
Rustls Outperforms OpenSSL and BoringSSL
- deleted 2y ago[deleted]
- 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
- deleted 2y ago[deleted]
- mjevans 2y agoA comparison to https://en.wikipedia.org/wiki/LibreSSL https://en.wikipedia.org/wiki/LibreSSL would also be nice.
- somat 2y agoLibressl is openssl with a coat of paint (a sane interface) and improved documentation. They are doing good solid work, but I would not expect any dramatic improvements in security and seeing as the openbsd project values correctness over speed, very likely a small hit in the speed department.
- zdw 2y agoLibreSSL also has focused on removing code which is viewed as being actively bad (poor/problematic reimplementations of stdlib features), or less valuable or not aligned with OpenBSD's goals (ex: FIPS support). It's probably worth benching just to see the impact of these changes - the fork happened around the same time as BoringSSL, which as these graphs show has quite different perf characteristics.
- cesaref 2y ago'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.
- ctz 2y agoNote that the AVX-512 code we're referring to is the code that Intel also contributed to OpenSSL. As a side-note, I believe the CPU we tested this on does not suffer from the AVX-512 power limits reported with earlier AVX-512 parts. https://travisdowns.github.io/blog/2020/08/19/icl-avx512-freq.html#rocket-lake https://travisdowns.github.io/blog/2020/08/19/icl-avx512-fre... seems to confirm that.
- deleted 2y ago[deleted]
- anitil 2y ago~That page is the first I've heard of license-based downclocking. I know there's no ethical reason not to do it, and it's similar to fusing a higher/lower performance chip out of the same base design, and free-market etc. But it just makes me sad.~ Edit: Based of this comment [0] and replies, it appears I've misunderstood what 'license' means. My apologies [0] https://news.ycombinator.com/item?id=24218310 https://news.ycombinator.com/item?id=24218310
- cesaref 2y agoAh, ok. So the frequency locking was to reduce jitter on the performance tests? If so, this makes sense.
- 2y ago
- jedisct1 2y agoMore 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.
- colmmacc 2y agoI'm super proud of the work that the aws-lc team have been doing. Insanely powerful optimizations on many platforms (not least Graviton!) ... and those optimizations are formally generated or formally verified (see https://github.com/awslabs/s2n-bignum https://github.com/awslabs/s2n-bignum and https://github.com/awslabs/aws-lc-verification https://github.com/awslabs/aws-lc-verification for directly related work) and also make massive improvements to the constant-timeness of the operations, which is important for mitigating side-channels. I suspect most of the team would tell anyone "We have to write this in Assembly and C, but you don't have to! Rust is what we prefer to see at the application layer."
- pjmlp 2y agoWell, that is true of any compiled language that still happens to have some of its parts written in either C or C++ instead of being fully bootstrapped.
- pornel 2y agoThis has been a deliberate design choice, because these primitives typically have to be constant-time, and are full of tricks to avoid CPUs' side channels. It's a very delicate code that is dangerous to rewrite. However, TLS still involves a lot of code code that isn't pure low-level cryptography, like numerous protocol and certificate parsers, CA store interface and chain validation, networking, protocol state handling, etc.
- nickpsecurity 2y ago“ Rustls is a memory safe TLS implementation with a focus on performance.” If the other commenter was right, then what they’re saying is that people seeing a Rust TLS stack outperform non-Rust stacks might assume critical operations were written in memory-safe Rust. Then, that the post was implying memory-safe Rust is fast even with low-level operations. That maybe they could use Rust to replace C/C++ in other low-level, performance-critical routines. Then, they find out the heavy-lifting was memory-unsafe code called by Rust. It does feel misleading if a reader thought Rust was replacing ASM/C/C++ in the low-level parts. I mean, even the AI people are getting high performance wrapping unsafe accelerator code in Python. So, what’s that prove? In these situations, I might advertise that the protocol engine is in memory-safe code while the primitives are still unsafe. Something like that.
- mmastrac 2y agoMy 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.
- dochtman 2y agoHow so? What standards do you need support for?
- mmastrac 2y agoAs a library vying to replace OpenSSL, the same set of suites as OpenSSL. I'm no longer blocked on this particular issue that I filed on behalf of my work at Deno, but they aren't interested in adding less-secure suites that may be required by certain server configurations, but still appropriate for traffic that isn't general web-use. https://github.com/rustls/rustls/issues/1607 https://github.com/rustls/rustls/issues/1607 At some point I had a list of suites required to connect to some older versions of MySQL/Microsoft SQL Server, but again, no longer blocked. For server-to-server use where I don't control one end of the equation, I stick with the OpenSSL crate. If there's potentially older servers in the mix, I'm OK with using rustls as a backend for things like reqwest, but it'll be openssl for servers for now. I understand the philosophy, but rustls is never going to be an OpenSSL drop-in until this approach changes. Semi-related, I now avoid native-tls because MacOS + gatekeeper + weird JAMF configuration makes that library completely unreliable in the wild.
- LinuxBender 2y agoWill RustTLS support ECH? I would like the ability to hide the real server name in the SNI handshake to HAProxy.