Hacker Remix

Rustls Outperforms OpenSSL and BoringSSL

93 points by jaas 16 hours ago | 25 comments

cesaref 8 hours 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 8 hours ago

Note 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-fre... seems to confirm that.

cesaref 16 minutes ago

Ah, ok. So the frequency locking was to reduce jitter on the performance tests? If so, this makes sense.

anitil 3 hours 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

mmastrac 6 hours ago

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.

jedisct1 7 hours ago

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.

colmmacc 7 hours ago

I'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 and 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."

pornel 5 hours ago

This 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 5 hours 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.

tptacek 4 hours ago

It's a post about a memory safe TLS stack outperforming the dominant memory unsafe TLS stack, with metrics. The only observation that detractors are making is that, as with virtually every TLS stack, the lowest-level cryptography primitives are done in assembly. Ok, and?

nickpsecurity 48 minutes ago

Because, by definition, it’s not a memory-safe, TLS stack at that point. Security is only as strong as its weakest link. If critical components aren’t memory safe, we don’t usually call it memory safe overall or claim it’s in a memory safe language without clear qualifiers.

The detractors are talking about how they’re marketing or describing it. They want the memory safe and Rust labels to only be used for memory safe and purely-Rust programs. That’s fair.

Outside the marketing, the stack is good work. I’m grateful for all the TLS teams do to keep us safer.

ozgrakkurt 31 minutes ago

I am switching to zig after writing rust professionally for 5+ years, but this take doesn’t make any sense having small amount of unsafe primitives is not the same as having all of your code unsafe. Especially higher level logic code can have a lot of mistakes, and the low level primitives very likely will be written by more experienced and careful people. This is the whole point of rust, even if it is questionable if it reaches it. Title only says rustls beats the other libraries which is objectively true so don’t see what is misleading here.

10 hours ago