Use OpenSSL instead of LibCrypto?

[a-ungurianu]

Given that with the split of Ladybird out of the SerenityOS project, it is now permitted to use external libraries, should the self written crypto implementation we have in LibCrypto be replaced with more canonical libraries (such as OpenSSL)?

On a cursory look, this is what NodeJS does, and I assume other browsers as well?

[wmentha]

OpenSSL uses the Apache-2.0 license.

Alternatively, Botan uses the BSD-2-clause license like Ladybird.

[ADKaster]

We previously pulled in WolfSSL but then backed it out because we had forgotten to check the license 😅. So yes, replacing LibCrypto with an audited FOSS crypto library is a good idea.

[circl-lastname]

What's the situation now though, since curl uses OpenSSL, and Ladybird uses curl, does this cause a licensing issue? Additionally will LibCrypto still be needed if WebSockets are moved to a 3rd party library?

[stelar7]

Additionally will LibCrypto still be needed if WebSockets are moved to a 3rd party library?

LibCrypto is still used in LibJS, as part of Web Crypto API

[awesomekling]

The two main blockers I'm aware of are Web Sockets and Web Crypto.

Web Sockets currently relies on LibTLS which relies on LibCrypto. Web Crypto relies on LibCrypto directly.

We definitely want to use a library like OpenSSL instead of our own crypto.

[fdellwing]

OpenSSL uses the Apache-2.0 license.

BSD-2-Clause should be compatible with Apache-2.0 though.

[RubenKelevra]

How about rustls? It offers much better multithreading performance and is written from the ground up by following RFCs, so the goal is similar to Ladybirds goal.

It offers MIT, Apache-2 and ISC license, so it's compatible with BSD-2.

[manuel-za]

How about rustls?

• rustls uses aws-lc-rs as the default cryptographic provider
• aws-lc-rs is a rust wrapper around awc-lc
• aws-lc is "maintained [...] for AWS and their customers" and based on BoringSSL and OpenSSL
• "BoringSSL is a fork of OpenSSL that is designed to meet Google's needs."

I'm guessing the answer is: "no."

[circl-lastname]

Just because it's Google doesn't mean its forbidden. We use Skia here

[RubenKelevra]

Not just Skia, Ladybird started to use the ANGLE library which is also developed by Google for WebGL recently.

Apart from that just because aws-lc is based on OpenSSL and BoringSSL doesn't mean it depends on development by either of them. It's a fork.

[colleirose]

How about rustls?

* `rustls` uses [aws-lc-rs](https://crates.io/crates/aws-lc-rs) as the default cryptographic provider

* `aws-lc-rs` is a rust wrapper around [awc-lc](https://github.com/aws/aws-lc)

* `aws-lc` is _"maintained [...] for AWS and their customers"_ and based on [BoringSSL](https://boringssl.googlesource.com/boringssl/) and OpenSSL

* _"BoringSSL is a fork of OpenSSL that is designed to meet Google's needs."_

I'm guessing the answer is: "no."

aws-lc is specifically designed to be based on BoringSSL but usable by anyone (the biggest problem with BoringSSL is that it's only intended for internal Google use and is therefore poorly documented). Just because Google and/or Amazon influenced the design of something doesn't mean it's inherently problematic or insecure; these libraries are not black magic and the entire point of open-source software is that you don't have to trust that the maintainer is decent for the code you use to still be good.

The only feature I'm aware of aws-lc lacking from OpenSSL is Ed448 compatibility. If aws-lc is ever audited, it would be, IMO, the best replacement for OpenSSL, due to both performance and security. rustls is (very unfortunately) ultimately just a wrapper around aws-lc in this case. The original idea behind rustls was to base it on the ring library, but ring is experimental and so aws-lc-rs became the default, but aws-lc-rs is just a wrapper around a memory-unsafe library, and therefore we no longer would have the benefit of memory safety vulnerabilities being less likely, while still having to deal with the complexity from maintaining the integration between Rust and C. (I would support implementing some code in Rust at some point, but this isn't a case where it's practical.)

If there's actually interest in moving away from OpenSSL, the most obvious place to start would be replacing invocations of RAND_bytes with the CSPRNG function from either aws-lc or libsodium, given issues like this with the OpenSSL CSPRNG function, which is way more complex than it needs to be.

[manuel-za]

the entire point of open-source software is that you don't have to trust that the maintainer is decent for the code you use to still be good.

...and yet, here we are, building a whole browser from scratch vs. "not having to trust that the maintainer [of Chromium] is decent"...

The conversation here (opinion):

• ... is NOT about replacing OpenSSL with something else. I trust the maintainers to make those calls:
  • Minimizing dependencies on Google/Amazon/Meta/Microsoft seems sound
  • Taking a deep breath before adding a whole other language toolchain seems like another excellent idea
• ... is about replacing LibCrypto. The case for "with OpenSSL" is mainly based on:
  • We are using it already
  • We probably don't need a scientific-grade floating point library but just primitives (BigInt, BigFraction, ...) needed by LibJS (see #2639)

We definitely want to use a library like OpenSSL instead of our own crypto

I would be happy to take a crack at replacing LibCrypto with an OpenSSL wrapper, but would be good to know that this is aligned with the project (vs., say, mpfr)... It seems a good size undertaking.

[fdellwing]

This issue is very outdated as the bulk of security relevant code is already replaced by OpenSSL (wrappers).

[colleirose]

the entire point of open-source software is that you don't have to trust that the maintainer is decent for the code you use to still be good.

...and yet, here we are, building a whole browser from scratch vs. "not having to trust that the maintainer [of Chromium] is decent"...

The conversation here (opinion):

• ... is NOT about replacing OpenSSL with something else. I trust the maintainers to make those calls:
  • Minimizing dependencies on Google/Amazon/Meta/Microsoft seems sound
  • Taking a deep breath before adding a whole other language toolchain seems like another excellent idea
• ... is about replacing LibCrypto. The case for "with OpenSSL" is mainly based on:
  • We are using it already
  • We probably don't need a scientific-grade floating point library but just primitives (BigInt, BigFraction, ...) needed by LibJS (see #2639)

There's a big difference between using an entire browsing engine from Google vs using cryptographic primitives from Amazon.

I would be happy to take a crack at replacing LibCrypto with an OpenSSL wrapper, but would be good to know that this is aligned with the project (vs., say, mpfr)... It seems a good size undertaking.

LibCrypto mostly already is.

This issue is very outdated as the bulk of security relevant code is already replaced by OpenSSL (wrappers).

That's a fair point and I'm not sure what exactly my point was when I talked about why aws-lc is still a good library given that OpenSSL is already being used. I assumed that because the issue was still open there was some desire to use a different library or something like that. If OpenSSL is already being used for most of the primitives, should this issue be closed?

[ADKaster]

As mentioned, LibCrypto has been transitioned into a wrapper around OpenSSL. Discussions about using an alternative crypto library under the hood should be moved to their own issues (and justified with very good reasons ™️ to take on the technical and maintenance burden of such a change).

So yes, closing this