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.
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 Index of /pub/OpenBSD/LibreSSL/
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.
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.
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
indefinite.
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.
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).
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.
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.
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.
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) .
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 Tor Project | 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).
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.