Libressl vs Openssl

[c0rv4x]

Hey, I was trying to install OpenSSL from brew instead of the default one on the MacOS which turned out to be impossible. Specifically here is the error on brew install openssl@1.1

openssl@1.1 is keg-only, which means it was not symlinked into /usr/local,
because openssl/libressl is provided by macOS so don't link an incompatible version.

openssl version gives me LibreSSL 2.8.3

So looks like now MacOS is using LibreSSL. Would you recommend installing OpenSSL over it or use the Brew version of LibreSSL? Or may be something else?

[sesam]

OpenSSL is shunned by the cool kids recently. The blog posts about LibreSSL and BoringSSL make out that you might want to use Open when compatibility is crucial, Libre if you need all modern features, and Boring if you only need best practice features and have a couple of days to rework your code to integrate with Boring, since it's made to be less feature-packed and more boring, especially from vulnerability news point of view. Also, Google is paying out large sums for bugs in BoringSSL (as it's part of Chrome) so it has a good chance of being the safest SSL impl.

[drduh]

I probably wouldn't install OpenSSL from Homebrew unless I had a specific requirement to use it. When the OpenSSL section was written, the version being shipped was quite old, lacked features, and didn't use LibreSSL. It needs to be updated. @sesam has the right idea to get started.

[wAuner]

when you want to install wget from brew, it installs openssl (1.1) as dependency

[andrewcrook]

With homebrew the builtin LibreSSL remains de facto

>openssl version
LibreSSL 2.8.3

>which openssl
/usr/bin/openssl

OpenSSL 1.1 is a dependency for applications within homebrew externally,
also some packages are complied upon installation e.g using compiler flags within the formulae files.

I often wondered why applications haven’t moved to openssl 2 or 3 and/or alternatives

[johnsoga]

I often wondered why applications haven’t moved to openssl 2 or 3 and/or alternatives

This likely comes down to 1 of 2 reasons:

1. Licensing: it would seem starting in v3.0.0 OpenSSL has now migrated to the Apache License 2.0. While I'm definitely no licensing expert I've seen over and over how companies will avoid updating and ride out a current version until its EOL before upgrading or migrating over licenses. Seems just the idea of having to investigate whether it would affect them or (given legal language) the idea that they could be held legally responsible/accountable for something will freeze companies in their tracks. They paid to do the research once and have no desire to do it again. This is all to common with OSS.

2. Compatibility: In that same blog announcement:

   "Some applications may need to make changes to compile and work correctly, and many applications will need to be changed to avoid the deprecations warnings. We have put together a migration guide to describe the major differences in OpenSSL 3.0 compared to previous releases."

   Plenty of these companies again have paid the upfront cost to develop their platforms and then can continue to utilize them because (doing themselves no favors) OpenSSL continues to maintain the v1.1.1 release. So effectively it's the same issue here until there is a clear and present need the cost to refactor/redesign is likely not worth it to these companies.

As for using OpenSSL via Homebrew go ahead. Replacing the system LibreSSL binaries with the OpenSSL binaries would be a guaranteed bad idea and quick way to probably break lots of things on your machine. Installing OpenSSL via Homebrew will put its binaries with the rest of the things you install via Homebrew safely away someplace to not interfere with the systems built-ins

[johnsoga]

So looks like now MacOS is using LibreSSL. Would you recommend installing OpenSSL over it or use the Brew version of LibreSSL? Or may be something else?

You really don't have a choice here. macOS is not very BSD/*nix like in the sense that you can just recompile and overwrite system binary dependencies with a "drop-in" of your choice. Sadly it's just a mix of enough OSS and proprietary that there are plenty of things that can't really be taken apart and put back together. macOS is built to use LibreSSL so you're better of letting it. As for anything else you run build yourself by all means build against OpenSSL as far as I'm aware many of if not most of the package built in Homebrew that require an SSL library install with/build off of OpenSSL.

[johnsoga]

Looking into this further. I'm running the latest public release:

bash-3.2$ sw_vers
ProductName: macOS
ProductVersion: 12.1
BuildVersion: 21C52

and they're still using an old release of LibreSSL from December 15th, 2018:

bash-3.2$ openssl version
LibreSSL 2.8.3

The latest is LibreSSL 3.4.2 (November 25th, 2021). Looking over the release notes there has been no licensing changes, but given the goal of LibreSSL to essentially modernize and fix many problems (in particular documentation) from OpenSSL. I have noticed there has been a lot of updates to various functionality/APIs/etc. in many cases to fix incorrect behavior. So its very likely that Apple is dependent on an incorrect/unexpected behavior (for whatever reason) and is stuck using the version that has this behavior until they can resolve all dependencies on it. Although looking at the rate which LibreSSL is pushing out updates Apple should really hurry up as the situation only seems to be getting worse for them.

It's also equally possibly that Apple's build process is just kind of trash and so they may not have good/if any test cases and tooling setup to be able to quickly test deploying newer releases. So it may just take them a really long to to test so they'll always be several releases behind.

[johnsoga]

and Boring if you only need best practice features and have a couple of days to rework your code to integrate with Boring, since it's made to be less feature-packed and more boring, especially from vulnerability news point of view.

This seems mostly correct although per their own description Google themselves are admitting unless you have a reason to, you probably shouldn't be using BoringSSL.

"Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability."

[drduh]

I removed the section. If there's anything important to mention about implementations, please suggest a new section in a PR.