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.
'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.
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.
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."
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.
“ 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.
Libressl 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.
LibreSSL 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.
> 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.
Most 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.
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.
From 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.
The project is the best one for use on the internet with modern SSL standards, however.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
Comparing it to OpenSSL is a bit much.
That said, the performance speaks for itself here.