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-devto 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
indefinite.
madaidan via Whonix Forum:
Use LibreSSL by default in the Tor Browser (#33485) · Issues · Legacy / Trac · GitLab
Awesome!
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.
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
Tested?
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].
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.
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).
NSS (the thing mentioned in #28156) looks interesting.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
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.
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.
https://www.libressl.org/releases.html
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.
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.
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).
That links to TLS internal error running Tor 0.3.4.9 on Debian Buster (OpenSSL 1.1.1a) (#28616) · Issues · Legacy / Trac · GitLab
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 Regression: Tor's use of SSL_export_keying_material() broken with TLS 1.3 in Openssl 1.1.1a · Issue #7712 · openssl/openssl · GitHub
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.
Yes, there could be a fake openssl-dev package. But this also needs a plan how to undo these for users who upgrade which is hard once there is a higher version number installed fake package. More and more hacks piling up until I cannot see through anymore.
Unknown.
Depending on the bug, it doesn’t just need reporting, depending on the gravity of the bug, it would either require fixing (which I could not) or reverting to openssl.
Debian doesn’t just need suggestions, they need contributions.
I haven’t seen anyone trying to contribute this to debian and hitting a wall yet.
LibreSSL might have similar APIs as OpenSSL but simply replacing the OpenSSL libraries with LibreSSL libraries and preserving the old names of the libraries in system without changing the code and recompiling the user program might not work as expected. It depends on implementation and compilation details and needs to be actually tested.
It would also help to ask LibreSSL developers explicitly if replacing the OpenSSL files which previously were provided by OpenSSL such as /usr/lib/x86_64-linux-gnu/libssl.so.1.1 is supported / sane / expected or if recompilation is advised.
LibreSSL was forked from OpenSSL in 2014. In these 6 years since, has one project have had a better track record then the other?
This would need some more citations. Also major distributions switching to LibreSSL or at least discussing this would help.
LibreSSL sounds really good indeed:
But things need to be done the correct™ way:
Within 1 year, LibreSSL mitigated plenty of vulnerabilities (including 5 critical ones) which OpenSSL was affected by.
https://www.openbsd.org/papers/libtls-fsec-2015/mgp00005.html
Dunno what the current total of vulnerabilities mitigated is but I expect it to be quite high.
void deprecate libressl and switch back to openssl: