As part of my ongoing effort to evaluate FreeBSD as a server OS I took the time to see what it takes to replace OpenSSL with LibreSSL for increased system security.

I'm sure most of you are familiar with the beast that OpenSSL is and I wanted to see whether completely replacing OpenSSL with LibreSSL was a viable option.

Replacing OpenSSL with LibreSSL in FreeBSD 10.3 base

Thanks to Bernard Spil and the HardenedBSD team's ongoing efforts to increase security in the FreeBSD operating system we are now at a point where incorporating LibreSSL into the FreeBSD base system is a relatively straight forward option.

Disclaimer: I did not really do anything else other than trying to make Bernard's patches more accessible to everyone.

I branched off from the latest release tree (releng/10.3), added the current portable LibreSSL version (2.4.1) to src/crypto and Bernard's patches using git.

This has a few benefits over the original patch method:

You can check out the source that already contains the patches and that is guaranteed to compile

I expect this method to be easier to maintain as we are moving towards the release of FreeBSD 11

Git has a mechanism to test whether patches would apply successfully successfully before having to actually apply them (in comparison, the patch(1) command in FreeBSD is error prone. See closing thoughts below.)

TLDR;

In order to compile here's the necessary steps:

What does this mean for web developers?

Replacing OpenSSL in the base system is a huge step forward in making sure our systems are less vulnerable to security threats but the story doesn't end here.

Your stack is just as secure as its weakest link.

What about the packages and ports?

The FreeBSD pkg system installs precompiled versions which means any SSL dependency would have been built using OpenSSL. A way to work around this is to use the port system and compile packages manually.

Being a web developer I wanted to see how most common apps compile with LibreSSL so I did a few tests:

Software that compiled without errors:

nginx-devel-1.11.1

ruby23-2.3.1,1

postgresql95-client-9.5.3

postgresql95-server-9.5.3

go-1.6.2_1,1

elixir-1.2.6

erlang-18.3.4.1,3

git-2.9.0

fish-2.2.0 (because it's my favourite shell)

Software that needs more work: node.js

By looking at the most recent node vulnerabilities, it becomes obvious that most of these are related to OpenSSL itself. Part of the reason is that node comes with a version of OpenSSL bundled, which means that unless you upgrade your node ports on a regular basis and expose node over the internet (using Express or Ghost for example) chances are that your system is vulnerable.

There have been discussions around incorporating LibreSSL into node, but it was discarded mostly for not building on MSVC. As of LibreSSL 2.2.2, Visual Studio Native builds can be produced using CMake. This produces ABI-compatible libraries for linking with native code generated by Visual Studio. So there's hope but we are not quite there yet.

In case anyone wants to work on patches, the Gentoo community has started working on this already but their patches are for version 5.7.1 and so are a bit outdated. Nevertheless these might be a good starting point if someone wants to crack this.

How about alternative SSL implementations?

The Core Infrastructure Initiative is also working towards modernising OpenSSL but in all honesty I think they might be a little late to the party. Having seen how LibreSSL compares to OpenSSL I'd place my bet on LibreSSL, at least for now.

Google's BoringSSL is also an interesting effort but it's not a good idea to adopt it in your project. They are making this pretty clear:

BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs. 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.

According to Google, they will keep sending bug fixes to OpenSSL and will continue funding the Core Infrastructure Initiative and the OpenBSD Foundation.

For now LibreSSL seems to be the most viable alternative SSL implementation. It also originated in OpenBSD and so it's the most compatible with FreeBSD itself.

Closing thoughts

Are we likely to see LibreSSL making its way to FreeBSD base?

This is hard to tell, some ports are still not building against LibreSSL but it's not impossible. The forthcoming version of FreeBSD (v11) is past the code freeze stage and therefore won't land with full LibreSSL support. I can't imagine it arriving any time soon.

On the other hand OpenBSD already comes with LibreSSL in base and the HardenedBSD team already managed to successfully build FreeBSD 11 with LibreSSL.

Why forking instead of just using Bernard's patches directly?

Whilst Bernard's repository contains a single patch set, it did not work for me. This is due to the patch command's error prone behaviour that is mentioned in the man page:

patch usually produces the correct results, even when it has to do a lot of guessing. However, the results are guaranteed to be correct only when the patch is applied to exactly the same version of the file that the patch was generated from.

In order to ensure reproducible builds I chose git to keep track of the whole source tree instead of keeping patches separately. This also makes it easy to review diffs compared to FreeBSD's base.

Special thanks