LibreSSL by default

LibreSSL is a fork of OpenSSL by the OpenBSD team following Heartbleed. It improves security a lot from the original OpenSSL library and I think it should be used instead.



OpenBSD has a great track record of security and especially with crypto (see e.g. OpenSSH).

Some Linux distros are using LibreSSL by default already such as Void and Hyperbola.



It’s not yet available in Debian. There was an RFP but no progress was made.

I think we should package this ourselves and make it conflict with the OpenSSL package (so applications use it by default rather than needing to be re-built). Releases are available here https://ftp.openbsd.org/pub/OpenBSD/LibreSSL/

Examples of what the packaging would be are https://github.com/radhus/debian-libressl and https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=libressl-git

Having LibreSSL used by default would make it far less likely for there to be critical vulnerabilities in the TLS implementation such as Heartbleed.

This looks difficult.

Some Quotes from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754513 from people with e-mail address ending with @debian.org.

So far, it looks like a recompile could be necessary. But since the
upstream package has seen the light of day only yesterday (see
http://article.gmane.org/gmane.os.openbsd.announce/186 for the
announcement), things are not yet stable. For the technical side of the
discussion, you can read http://dir.gmane.org/gmane.os.openbsd.tech).

Packages currently build-depending on openssl should be able to
build-depend on “openssl-dev | libressl-dev”.

To translate, quote yet again, even more cut:

Packages currently build-depending on openssl

Meaning, package that currently use openssl would need to be patched to modify debian/control and re-compiled.

Tor Browser would probably not use it as it it’s a statically compiled binary (i.e. not using “much” system libraries). Tor Browser includes these files:


Please suggest LibreSSL to Tor and Tor Browser developers if applicable.


Would be a ton better to contribute to Debian directly.

In conclusion: I don’t think I will be working on this anytime soon.

  • I don’t think Whonix project is ready to take much more mammoth task. Long term sustainability work is required such as automated testing, refactoring (merging some packages), code documentation.
  • This might be possible if Whonix had a social / organizational structure similar to Debian with lots of trusted developers where each one maintains a few packages. But I guess that’s unrealistic for Whonix as most contributors want to stay anonymous.
  • Numerous bugfixes are required (partially maybe due to recent hardening). Here’s a partial list.
  • Other security todo items are also well stacked.
  • Other maintenance work not done yet such as this.
1 Like

Can’t we just add Provides: openssl-dev to our LibreSSL package?

It would be better but Debian is very slow at things like this. I don’t think we’d want to wait years for this.


Tor (not the browser), uses the system SSL libraries so we can just replace them with LibreSSL.

This doesn’t seem that big of a task. It’s not like we’re maintaining the actual program. Just creating a package.

We can work on all those at the same time. LibreSSL likely won’t add more bugs unless the user is trying to use ancient features LibreSSL removes which they probably shouldn’t be touching in the first place.

madaidan via Whonix Forum:

Can’t we just add Provides: openssl-dev to our LibreSSL package?

Maybe. But does it really work?

Quote Guus Sliepen guus@debian.org

It would be interesting to recompile all packages that Build-Depend:
libssl-dev with LibreSSL, and see what actually breaks…

My interpretation: requires recompilation and could break things. This
requires way more focus than available as a side project.

Specifically tampering with crypto in ways that could potentially /
likely do harm isn’t great to be done in a small distribution.

It would be better but Debian is very slow at things like this. I don’t think we’d want to wait years for this.

However doing too many things at Whonix makes Whonix unmaintainable. The
amount of things requiring time for maintenance cannot be expanded

1 Like

madaidan via Whonix Forum:



Tor (not the browser), uses the system SSL libraries so we can just replace them with LibreSSL.

Not easy. Tor Browser internal updater (no hook dispatched to know when
it runs) would either fail or change these back the upstream version.

1 Like

It doesn’t require recompilation if we replace the OpenSSL libraries with LibreSSL. The programs would be already configured to use those.

That’s unlikely. LibreSSL doesn’t remove much features except ones essentially nobody uses.

We aren’t the ones tampering with it. The OpenBSD team are.

madaidan via Whonix Forum:

It doesn’t require recompilation


if we replace the OpenSSL libraries with LibreSSL. The programs would be already configured to use those.

[1] You mean to replace file paths such as
/usr/lib/x86_64-linux-gnu/libssl.so.1.1? Or are these the same file paths?

That’s unlikely.

Shouldn’t take chances for crypto.

If it’s easy indeed, then it should be contributed to Debian instead.
Then it at least would have peer review from knowledgeable people.

Once it’s in Debian sid, it can go to Debian buster-backports and from
there it might be reasonable to download from Debian buster-backports
and upload to Whonix buster repository.

We aren’t the ones tampering with it. The OpenBSD team are.

We wouldn’t tamper with the SSL libraries directly indeed. What often
goes wrong when using crypto is the implementation. I.e. the proper
integration/use of crypto libraries. The crypto libraries themselves
might be OK but a mistake in how to use them can still result in a failure.

How linking openssl vs libressl works and all the technical details is
beyond me. I’ve not yet integrated either openssl or libressl ever or
wrote any major C program. Therefore I am not qualified to port from one
implementation to another unless Debian had simplified that to the level
of choosing one package vs another along with some authoritative
statements / documentation.

Also depends on answer to [1].

1 Like

Yes. The program would be configured to use OpenSSL so if we just swap the OpenSSL libraries with LibreSSL, it should already be using them.

1 Like

Got a response on the trac ticket.

Yeah, I don’t think this is going to happen. It is maybe a good idea in general, especially for relay diversity, but the only place Tor Browser uses openssl is with tor. We are much more likely to use #28156 (and we should get there soon).

1 Like

NSS (the thing mentioned in #28156) looks interesting.

1 Like
  • The core Tor protocol depends on on OpenSSL and has a variety of hardening and workarounds for unsafe options tailored for this library. It is not as simple as swapping it out for the other on the fly. Abruptly replacing them may have unforeseen security consequences even if it apparently works. This is something the Tor Project must explicitly switch to which will benefit the entire network and not something we should be doing. Who knows what fingerprinting this results in?

  • Maintaining a non packaged critical lib for crypto is a huge responsibility. Needs us to watch upstream security fixes like hawks and push out new updates or else we lag behind and ship with known holes. Going more paranoid here - we can be particularly vulnerable to tampering by bad actors who’ve taken over a dev machine.

1 Like

LibreSSL is forked from OpenSSL and maintains compatibility.

No it doesn’t. Tor doesn’t modify system libraries.

It is.

Tor Browser developer, sysrqb, said it would be a good idea in general in the ticket above.

There’s been plenty of discussion of LibreSSL on the Tor Project trac.

tor-ramdisk used LibreSSL.

Not once have I seen mention of security issues.

No, the Tor program uses the system SSL libraries. It’s the OS’s responsibility, not the Tor Project.

How is that any different from other packages?

OpenSSL/LibreSSL doesn’t create new releases all the time. It’s at a steady pace.


This is unlike hardened-kernel however (which you don’t seem to have any objection to) where new kernel versions are released around every 3 days and we do need to watch upstream like hawks.

What? If the dev machine is compromised, the attacker can do far more than just mess with SSL libraries.

1 Like

Remove patch for building OpenSSL reproducible

Do not warn about compatible OpenSSL upgrades

OpenSSL 1.1.1d fails to compile for some platforms/architectures

Disable TLS1.3 when openssl bug 7712 is present

Tor Browser ships its own version of openssl which they customize and sometimes add features to like reproducible builds before it was mainlined as seen above. The fact that it is also built against the system openssl is besides the point.

I have no objection as soon as they switch to it as a default. If it was simple they would have done it already or at least should easily be able to in the future.

Curious as to how libressl compares to bearssl or polarssl? If TPO devs are interested in switching then a ecosystem wide survey is beneficial.

The difference is we are not the maintenance team. Debian’s thousands of devs and security backports team are responsible for this normally whereas now we would be the ones holding the bag.

Yes and no. It may be much harder to ever find a small change to the compiled library’s RNG than a security vuln/backdoor that can be fuzzed or stumbled unto by accident. Inheriting reproducible packages from Debian would mitigate this. Theoretically we can do it too, but that’s already too much for an overflowing plate.

1 Like

That’s not what the linked issue is about. It’s “Disable TLS1.3 when openssl bug 7712 is present” which isn’t a modification of OpenSSL but disabling TLS1.3 usage within Tor.

This was a bug in Tor that complained about OpenSSL versions. Not a modification of OpenSSL.

Was a bug in the build script of the Tor Browser. Not a modification of OpenSSL.

Same as above.

Tor Browser was already discussed above and a trac ticket about switching it to LibreSSL was made.

Switching the system libraries has no effect on the browser anyway. We weren’t talking about that.

That doesn’t make sense. The Tor Project doesn’t manage the OS’s SSL libraries.

Those are their own completely different SSL libraries. We can’t use them as most apps want OpenSSL. LibreSSL is a fork of OpenSSL so it’d work with those apps.

They’ve already decided to switch to NSS. Read the above discussion.

We’re the maintenance team for hardened-kernel, the hardened_malloc package, the LKRG package, the tirdad package. etc. yet I don’t see any complaints about that from you.

If there’s hope of seeing Whonix adoption, please get the all clear from TPO devs either in another ticket or on their mailing list, if this safe. Also file a RFP with Debian or choose another minimalist crypto lib that’s already in Debian (while asking Tor devs about it first) .

1 Like

Tor devs already think it’s a good idea (and this is mostly irrelevant for Tor as it’s switching to NSS soon). A RFP was already made for Debian (it’s linked in the initial post). I’m not aware of a single other OpenSSL fork focused on security like LibreSSL.

Also, if there were any security issues with LibreSSL it would be widely known. The Tor Project even gives guides on how to setup relays on OpenBSD with 0 mention of security issues https://community.torproject.org/relay/setup/guard/openbsd/


Just now remembered:
Provides: does not work with packages that have versioned Depends:. For example (made up) Depends: openssl-dev >=1.01.
I know that, because when implementing anon-ws-disable-stacked-tor package by that time there was a package torchat which had a versioned depends on package tor. Therefore anon-ws-disable-stacked-tor couldn’t just do Provides: tor. That unfortunately wasn’t enough.

Well, could use a pacakge with the same name but higher version number but then just the amount of hacks is piling up at the downstream Whonix distribution. Lots of efforts in a hacking around this while the real solution didn’t get closer (in Debian).

That links to https://trac.torproject.org/projects/tor/ticket/28616

Running a simple Tor relay on Debian Buster seems to report TLS 1.3 related OpenSSL internal errors. Not entirely sure how a function named tls13_hkdf_expand can fail, but I’m sure OpenSSL found a way.

Nov 26 01:07:40.000 [warn] Unhandled OpenSSL errors found at …/src/common/buffers_tls.c:65:
Nov 26 01:07:40.000 [warn] TLS error: internal error (in SSL routines:tls13_hkdf_expand:—)

If someone reports a bug similar to this, then I have no idea or not even time to learn this.

The devil is in the detail. Perhaps I am wrong. Perhaps this is actually easy. The current maintenance load might blurry my view. I certainly must not be persuaded into doing things which seem infeasable to me.

There’s only a limited amount of maintenance that can be taken up by a small distribution like Whonix. It would be different when there was funding and two paid full time developers who are more clever than me. Then certainly a lot more could be done.

Meanwhile unfortunately the best way to make progress on this one is doing it in Debian. Then the switch in Whonix would be as easy as changing a package in package selection. With the added benefit that all of Debian users and derivatives could make use of this.


Can’t we just set the version number to the same as the openssl-dev package?

Do many packages even have version requirements for openssl-dev?

It was a bug in OpenSSL that was then fixed https://github.com/openssl/openssl/issues/7712

If there’s a bug, report it. Same as any other software.

It was already suggested to Debian 6 years ago and they haven’t done anything. I doubt we can do anything upstream.

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]