Submitted via IRC for Bytram
A Rust-based TLS library outperformed OpenSSL in almost every category
A tiny and relatively unknown TLS library written in Rust, an up-and-coming programming language, outperformed the industry-standard OpenSSL in almost every major category.
The findings are the result of a recent four-part series of benchmarks [1, 2, 3, 4] carried out by Joseph Birr-Pixton, the developer behind the Rustls library.
The findings showed that Rustls was 10% faster when setting up and negotiating a new server connection, and between 20 and 40% faster when setting up a client connection.
But while handshake speeds for new TLS connections are important, most TLS traffic relies on resuming previously negotiated handshakes. Here, too, Rustls outperformed the aging OpenSSL, being between 10 and 20% in resuming a connection on the server-side, and being between 30 and 70% quicker to resume a client connection.
Furthermore, Rustls also fared better in sheer bulk performance -- or the speed at which data is transferred over the TLS connection. Birr-Pixton said Rustls could send data 15% faster than OpenSSL, and receive it 5% faster as well.
Last, but not least, the Rustls creator also said his library only used half of the memory required to run OpenSSL, a major advantage.
In the past, OpenSSL has been often criticized for its large memory footprint and the large number of security bugs found in its code. Because Rustls was coded in Rust, the issues with security flaws are largely addressed by the design of the Rust language itself, which was designed from the ground-up to avoid memory-related security bugs.
Based on the results of these benchmarks, Rustls appears to have also addressed the issue of performance, making it an ideal replacement for web services that still rely on the old OpenSSL.
(Score: 2, Informative) by Anonymous Coward on Saturday July 20 2019, @03:13PM (6 children)
So it's basically useless.
(Score: 0, Disagree) by Anonymous Coward on Saturday July 20 2019, @03:21PM (5 children)
Bullshit is strong with you. Check the repo it is a rust implementation and use rust lib for crypto and PKI validation
(Score: 1, Informative) by Anonymous Coward on Saturday July 20 2019, @04:47PM (4 children)
https://briansmith.org/rustdoc/ring/index.html [briansmith.org]
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @08:47PM (1 child)
Why are you talking about some library called Ring, when the article is about Rustls?
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @08:51PM
https://github.com/ctz/rustls [github.com]
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @02:29AM
Primitive not lib have a look at the code, ignorance is curable
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @06:02AM
https://github.com/briansmith/ring/blob/master/src/rsa/signing.rs [github.com]
What a wrapper
(Score: 2) by hendrikboom on Saturday July 20 2019, @03:32PM (11 children)
It would be interesting to see what performance one could get by hand-translating the rust code into C.
If the Rust code has a speed advantage because it is more comprehensible, thereby enabling the programmer to better use his intelligence rather than coding talent, the the hand-translated c code should have the same performance advantage.
But if it's faster because Rust has a better local code generator than gcc, the C code won't be as fast.
in any case, I support using bug-resistant languages. Especially for safety-critical components.
(Score: 2) by hendrikboom on Saturday July 20 2019, @03:36PM (4 children)
Of course it's possible that the constraints on memory usage in Rust provide additional opportunities for local code optimization because less static analysis is needed to determine aliasing issues. Can LLVM make use of that?
(Score: 3, Insightful) by JoeMerchant on Saturday July 20 2019, @05:46PM (3 children)
Whatever "magic" has happened in Rust could be recoded into C/C++ and happen there just as well- probably better if it's being tailored specifically to the OpenSSH application instead of broad-stroke implemented in the context of a general purpose language.
Same could be said of hand-coded assembly, though almost nobody has the patience to paint with a brush that small, anymore.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @05:28AM
When C++ is used with RAII instead of littering new and delete everywhere (bonus points if new/delete are interspersed with malloc/free by somebody who doesn't want to confine malloc/free to a C++ wrapper for that C lib they want to use), it's fairly safe. Unless the algorithm/program is multithreaded to take advantage of multiple CPU cores, Rust's only advantage is that it forces the developer to use RAII.
Incels gotta give up C++ or organize. C++ has too many features that are dangerous in the hands of a code cowboy, but unless software developers organize, we will never get rid of the code cowboys. If the Margaret Hamilton article hadn't been about male gazing at her, it could have been a discussion about software reliability instead (this comment [soylentnews.org] seemed the only relevant one).
(Score: 3, Interesting) by driverless on Sunday July 21 2019, @09:01AM
The magic isn't the use of Rust, it's comparing it to OpenSSL. Shit, if I wrote a TLS library in Visual Basic I'd make sure I compared it to OpenSSL because it'd come out looking better. OpenSSL serves as the point-zero baseline that everything is less buggy than, better written than, less full of vulns than, less ...
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @05:23PM
OpenSSL. OpenSSH is a completely different unrelated thing written by competent people.
(Score: 3, Interesting) by Anonymous Coward on Saturday July 20 2019, @04:25PM (2 children)
Openssl *intentionally* slows down some operations to prevent side-channel attacks (e.g., same number of steps for success and failure). I wonder if this new rust library is doing something wrong?
(Score: 5, Insightful) by JoeMerchant on Saturday July 20 2019, @05:50PM (1 child)
I wonder what all this new rust library is doing wrong.
They put it up against the performance benchmarks, did they really test it over all the security concerns?
I'll buy that OpenSSH could be more efficient and still achieve its security goals, I don't readily accept that a first pass implementation, in any language, has covered all the security goals that OpenSSH has met throughout its development history.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @10:32PM
What's all that talk about OpenSSH suddenly? Despite their names, Openssh and Openssl do not share common heritage.
(Score: 4, Insightful) by JoeMerchant on Saturday July 20 2019, @05:42PM (1 child)
I'm sure this was written as a "Rust is GREAT!" piece, but on the face of it, I'm taking it to be more of a "OpenSSL is a steaming pile of legacy code mired in too much FUD to change it..."
🌻🌻 [google.com]
(Score: 1, Insightful) by Anonymous Coward on Sunday July 21 2019, @02:48AM
Not to mention that this new implementation is probably free of all of OpenSSL's IFDEFs for all the platforms and architectures it supports.
(Score: 2) by JoeMerchant on Saturday July 20 2019, @06:40PM
I'll give you 10:1 odds that the C code generator (gcc7 on a "standard" Intel platform) will be faster than Rust.
🌻🌻 [google.com]
(Score: 2, Funny) by Runaway1956 on Saturday July 20 2019, @03:44PM (1 child)
It probably won't be welcomed in Texas, or any other west/southwestern state.
(Score: 2) by Farkus888 on Saturday July 20 2019, @06:34PM
Yeah but the northeast finished implementation 10 minutes after they had the idea.
(Score: 5, Insightful) by Anonymous Coward on Saturday July 20 2019, @03:58PM
Yeah.... well, that's not it.... failure to even identify the main security issues with OpenSSL does not bode well and saying "we don't have problems because 'insert tool'" is gold.
https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6 [medium.com]
(Score: 5, Interesting) by The Mighty Buzzard on Saturday July 20 2019, @04:08PM (10 children)
While I quite enjoy playing with Rust, I wouldn't use anything written in it as anything but a toy at this point. Yes, it's downright nifty what the memory and threading protections it promise but they're far from the only thing that can go horribly wrong with a crypto library. Add to that the fact that most libraries written it are pretty close to alpha-or-beta-quality garbage with their developers picking how they're written based on what's trendy and you should see why using it on anything important over openssl or even libressl would be a very, very bad idea.
My rights don't end where your fear begins.
(Score: 4, Interesting) by digitalaudiorock on Saturday July 20 2019, @05:44PM (7 children)
I've avoided Thunderbird 60.x under Gentoo because of it's rust requirement. Seeing that the entire source code for gcc-8.3 is just over 60 MB and the rust source is over 250 MB they can keep it...wreaks of the Mozilla bloat taken to the compiler level frankly.
(Score: 2) by The Mighty Buzzard on Sunday July 21 2019, @05:20AM (4 children)
The compiler size isn't really relevant unless you're running off fifteen year old disk storage. The reason it's much larger is because it checks and does a whole lot more than gcc does. The language itself is pretty solid and produces fairly tight binaries (not C/C++ tight but a hell of a lot better than high level languages) but I wouldn't build anything for payment with the vast majority of the libraries on crates.io. Maybe in ten years once they've gone through a decade of idiocy removal like all the well established languages had to do they'll be passable but right now they're garbage.
My rights don't end where your fear begins.
(Score: 2) by digitalaudiorock on Sunday July 21 2019, @06:07PM (3 children)
Well yea, but the real issue when it comes to a source based distribution like Gentoo is the compile time of all that source...though yes, that's more of an issue on older systems which mine are, I confess. Adding a whole new compiler just for Thunderbird pretty much tells me it's time to move to Claws Mail or whatever. Then again, I've totally had it with the Mozilla devs no matter what language they use.
(Score: 2) by The Mighty Buzzard on Monday July 22 2019, @10:55AM (2 children)
Right there with you. Calculate may be "Gentoo with an official BINHOST" but one little USE change and it's back to plain old Gentoo. And the newest box I own is nine years old.
My rights don't end where your fear begins.
(Score: 2) by digitalaudiorock on Monday July 22 2019, @02:43PM (1 child)
Haha...yup. On the machine I'm on right now I'd have to time "emerge rust" with a calendar ;).
(Score: 2) by The Mighty Buzzard on Monday July 22 2019, @03:14PM
I don't do it that way myself. It's much easier and faster to install as a user. Granted, it means some PATH tweaking if you want it to work as easily as system binaries but the rustup route is worlds faster than updating via portage.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @01:05PM
I'm a lot more radical. I avoid software that is not "obsolete", "legacy" or "deprecated" because those are the most stable and we do live in a shitty software age.
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @06:04PM
read the rust book and then see if you still feel that way.
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @04:13PM (1 child)
I think your argument is that a new implementation of OpenSSL or similar is dangerous in *any* language, even C or C++. I agree. But that's not a specific argument against Rust.
As for alpha and beta libraries - even the best C and C++ developers in the world make memory mistakes sometimes. So Rust libraries might be buggy, but it's not like the C/C++ world is rainbows and unicorns. It might be worth a shot.
(Score: 2) by The Mighty Buzzard on Monday July 22 2019, @11:00AM
Oh, sure, it's worth doing. It's just bloody stupid to use the resulting library in a production environment if you care about security even a little bit. Decades of having people actively looking for your mistakes vs. weeks of them doing so makes a damned important difference. And that's without even considering that most Rust libraries lurve the CoC more than they lurve having the best contributors.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Saturday July 20 2019, @04:32PM (1 child)
OpenSSL has been security audited by a recognized third party. Otherwise, rolling your own crypto is a bad idea.
(Score: 1, Interesting) by Anonymous Coward on Saturday July 20 2019, @04:53PM
It uses ring, which uses BoringSSL's crypto, which Google doesn't recommend for general use...
(Score: 5, Interesting) by Anonymous Coward on Saturday July 20 2019, @09:11PM (1 child)
Their main speed increase appears to be due to a memory copy that OpenSSL has, but this implementation eliminated.
Except that memory copy is there to ensure that the both successful and failing operations take the same amount of time. Information leaks out, and can be used to crack the encryption as a result.
So this library appears to be a total fail.
(Score: 4, Informative) by hwertz on Sunday July 21 2019, @06:33AM
This. OpenSSL has intentional delays inserted, a few years back some clever security researchers determined they could get enough infromation leakage from timing attacks to reduce the key search space "somewhat"... as I recall it wasn't a huge amount, but why get a 2048 bit key if leaks are going to reduce it to like 2000 bits?
That said, I like the concept of Rust. I like the likes of Java and Python, but Rust looks really like a more C-like language that avoids or works around C's big pitfalls.
(Score: 0) by Anonymous Coward on Sunday July 21 2019, @12:24PM
Not quite as secure tho...