[HN Gopher] Rustls Outperforms OpenSSL and BoringSSL
___________________________________________________________________
Rustls Outperforms OpenSSL and BoringSSL
Author : jaas
Score : 58 points
Date : 2024-10-22 13:29 UTC (9 hours ago)
(HTM) web link (www.memorysafety.org)
(TXT) w3m dump (www.memorysafety.org)
| favorited wrote:
| > 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.
| tptacek wrote:
| 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.
| akira2501 wrote:
| > tend not to implicate constructions Rustls would use.
|
| 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.
| tptacek wrote:
| It's replacing the bad C code. Not all C code is
| equivalently easy or difficult to write.
| mannyv wrote:
| Are the improvements due to AWS-LC ie: what about a test of
| that without the rust wrapper?
| adzm wrote:
| 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.
| wbl wrote:
| Cryptography functions are much safer than parsers or complex
| protocol logic.
| quadhome wrote:
| AWS-LC was forked from libcrypto, but it's also (partially)
| been formally verified.
|
| Comparing it to OpenSSL is a bit much.
| j-krieger wrote:
| Prefix Note: I am a Rust Nerd
|
| 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.
| mjevans wrote:
| A comparison to https://en.wikipedia.org/wiki/LibreSSL would also
| be nice.
| somat wrote:
| 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.
| zdw wrote:
| 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.
| cesaref wrote:
| '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 wrote:
| 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.
| jedisct1 wrote:
| 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 wrote:
| 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."
___________________________________________________________________
(page generated 2024-10-22 23:00 UTC)