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) 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]