Rust-Written Rustls Now Reportedly Outperforming OpenSSL & BoringSSL

[Errinwright]

Is it Rust, or is it doing away with legacy and utilising modern coding practices?

After reading more posts, it seems it could be more unRust reason than stated. See how it pans out. Hooeyfully no game changing security holes form, reducing the overall performance.

There are likely multitudinous reasons, but writing Rust is seemingly easier than equivalent in C (disregarding all other factors such as security and the learning curve). Furthermore, code maintenance of Rust implementations have become the most desirable aspect to undertaking the ordeal of major rewrites.

[stiiixy]

I understand the situation if you as the developer feel as if a project has long passed its rewrite life, best start from scratch. We see this a lot. This is a security project though, so while performance, especially for big iron, is important, security is paramount?

edit: supposed to be workin, not jibberjabberin 🤪

[Daktyl198]

Is it Rust, or is it doing away with legacy and utilising modern coding practices?

After reading more posts, it seems it could be more unRust reason than stated. See how it pans out. Hooeyfully no game changing security holes form, reducing the overall performance.

You're right that it's mostly just starting fresh with a modern codebase and using modern coding practices. But Rust is very performant, and is designed in a way that makes taking advantage of multiple threads easy. That doesn't impact every project, but for those it does it's nice. Plus the memory safety bit, but to be honest since the Swift 6 release I've actually been looking at it as a semi-memory-safe language that is nicer to use than Rust.

[ssokolow]

The standard library is full of unsafe.
Any system calls will use unsafe code.
Any hardware interaction at all will use unsafe code.
You literally can't do anything useful without either writing unsafe code or depending on third-party unsafe code.
That's simply the reality of systems programming.

Just because you're outsourcing your unsafe code from 400 micro-libraries written by pajeets and troons doesn't mean you're free of unsafe.

[image: not sure if arguing in bad faith or just stupid]

Nobody ever said that Rust magically let you build a system without memory-unsafe code. The point of Rust is that it's fenced off in little labelled boxes where you can audit it and trust that, as long as those are bug-free, the compiler will prevent the rest of the code from exploding because you accidentally returned a pointer to some variable in a stack frame that's now gone or mis-counted the length of your array by one.

(And yes, there have been various efforts, past and present, to formally prove that various parts of the Rust standard library are correct so long as the OS code and hardware they depend on uphold their promises.)

[Shnatsel]

unsafe code from 400 micro-libraries

This is the entire dependency tree for rustls:

rustls v0.23.15
├── aws-lc-rs v1.10.0
│ ├── aws-lc-sys v0.22.0
│ │ ├── libc v0.2.159
│ │ └── paste v1.0.15 (proc-macro)
│ ├── mirai-annotations v1.12.0
│ ├── paste v1.0.15 (proc-macro)
│ ├── untrusted v0.7.1
│ └── zeroize v1.8.1
├── log v0.4.22
├── once_cell v1.20.2
├── rustls-pki-types v1.10.0
├── rustls-webpki v0.102.8
│ ├── aws-lc-rs v1.10.0 (*)
│ ├── rustls-pki-types v1.10.0
│ └── untrusted v0.9.0
├── subtle v2.6.1
└── zeroize v1.8.1

[mobadboy]

I am incredibly surprised. The systems programming language thats much harder to fuck up writing optimized code winds up being the fastest. How could that ever be the case? It just doesn't make sense... my old teammates cousin told me that Rust was slow and bloated.

The standard library is full of unsafe.
Any system calls will use unsafe code.
Any hardware interaction at all will use unsafe code.
You literally can't do anything useful without either writing unsafe code or depending on third-party unsafe code.
That's simply the reality of systems programming.

Just because you're outsourcing your unsafe code from 400 micro-libraries written by pajeets and troons doesn't mean you're free of unsafe.

skill issue. maybe you can only write unsafe LOL

[jacob]

The standard library is full of unsafe.
Any system calls will use unsafe code.
Any hardware interaction at all will use unsafe code.
You literally can't do anything useful without either writing unsafe code or depending on third-party unsafe code.
That's simply the reality of systems programming.

Just because you're outsourcing your unsafe code from 400 micro-libraries written by pajeets and troons doesn't mean you're free of unsafe.

The point is to have the actual security-critical logic, in this instance crypto, use safe code. In rustls, there are a few instances of "unsafe" like this:

let mut stdin = unsafe { File::from_raw_fd(stdin_lock.as_raw_fd()) };

Also, there is a common misunderstanding about that "unsafe" means. It does not turn Rust into C. In reality, unsafe Rust is still safer than modern C++. In particular "unsafe" does not disable the borrow checker or the very strong typing.

[Almindor]

Also, there is a common misunderstanding about that "unsafe" means. It does not turn Rust into C. In reality, unsafe Rust is still safer than modern C++. In particular "unsafe" does not disable the borrow checker or the very strong typing.

I'd be careful here. `unsafe` in Rust is actually in many ways more dangerous than plain C or even assembly. The reason for that is that in `unsafe` blocks, you (as in the programmer) are responsible for ensuring that the invariants expected by the compiler are upheld on the unsafe/safe barrier.

This, as it turns out, is quite difficult and tricky in some cases. It can definitely be much more murky than plain old C. I'm saying this as an embedded rust developer and generally a big rust fan.

For anyone more interested in Rust and `unsafe`, I strongly suggest going over the Rustonomicon at https://doc.rust-lang.org/nomicon/

[skeevy420]

Dammit. Y'all were so close. RuSSL.

In the words of my generation, UP YOURS!

[Kemosabe]

Nobody ever said that Rust magically let you build a system without memory-unsafe code.

Not really.