[RFC] Switching back to OpenSSL

[Johnnynator]

OpenSSL nowadays doesn't have the issues anymore it had back in 2015 and significantly more Contributors watching and improving it. LibreSSL usually lacks behind in terms of supported algorithms and doesn't support the same API. Libs like Qt dropping support for OpenSSL 1.0 makes it significantly harder to maintain a (correct) patchset for LibreSSL support.

OpenSSL Pros

• Not that many (potentially wrong) patches needed, proper upstream support for nearly ever lib/program
• Potentially faster on non x86_64 platforms
• Access to newer Algorithms earlier
• No ABI breakage every 6 month

LibreSSL Pros

• Potentially safer by default (?)

[travankor]

Another advantage: OpenSSL is switching to a license OpenBSD considers non-free (Apache-2.0, which Void considers free). This means the codebase between openssl and libressl is more likely to diverge.

I think having better software (ie: haskell ssl library keeps breaking with libressl) and hardware support (ie: aarch64 crypto acceleration) is more useful for Void than security (not that openssl is super insecure these days).

[q66]

I'd argue that OpenSSL is safer, since it just gets a lot more attention and audit nowadays. Since heartbleed a lot of attention has gone to OpenSSL, it's probably one of the better-audited projects nowadays.

The performance increase on non-x86_64 platforms is not "potential", it's there; OpenSSL has optimized assembly code for most architectures, in addition to plain C fallbacks - LibreSSL does not have them, they all got dropped with the exception of the x86_64 ones.

So, +1 from me.

Perl being required for build is a non-problem, it's already required for build in several other bootstrap packages, including coreutils, gcc and glibc.

[pullmoll]

I had myself several times where it was difficult to see in which way patching a source for libressl would be correct. This is because I do not know every detail of the differences between the openssl versions 1.0.x and 1.1.x, and the libressl API lies somewhere in between the two.

So from my point of view using openssl could save us lots of work, and if a majority thinks that openssl is audited well enough nowadays, I'm pro switching.

[Hoshpak]

Are you talking about xbps as a project or the Void Linux xbps package? Switching all packages to openssl and still forcing every Void system to still install libressl in parallel through xbps would make it kind of pointless to switch in the first place.

I generally agree that we should switch to openssl. Libressl not supporting the openssl 1.1 API is increasingly holding packages back (I think I had issues when trying to update postfix in the past) and cannot be trivially patched. The slow movement of libressl development also bothers me and led me to not use it on my server. I am now able to connect to this server via TLS 1.3, just not from any of my Void machines.

[Johnnynator]

Simply don't switch xbps.

This would also imply to build libarchive against LibreSSL, but nevertheless I dislike having both LibreSSL and OpenSSL at the same time in the base system.

[Johnnynator]

We do have already multiple implementations at the same time, see mbedtls, gnutls, libressl, etc.

But not in the base system, there we only have LibreSSL as of now.

[Johnnynator]

E.g. I need to decide if ca-certificates depends on LibreSSL or OpenSSL (in theory I might be able to patch update-ca-certificates to work with both)

[travankor]

Anyway I've been thinking about it and maybe I'll switch xbps to use mbedtls. Not sure yet. So go ahead!

@xtraeme What about bearssl? In the link you provided above, it resists the attacks.

[travankor]

no, i meant for xbps, as an alternative backend

[Johnnynator]

@Johnnynator hmm I would not do this way. Each ssl implementation must depend on ca-certificates.

Yes, all ssl implementation depend on ca-certs but ca-certs depends on only one SSL implementation.
But the update-ca-certificates script right now ONLY works with libressl. And the openssl command does not have a proper way of querying whether it is OpenSSL or LibreSSL. (It always exits with 0, even when the command was not found..., so I need to judge it by what is print to stdout, argh...).

Edit: correction, OpenSSL exits with 1 on invalid commands, LibreSSL is the one that always exits with 0.

[Johnnynator]

in fact I haven't tried with openssl >= 1.1, but I think it would need minimal changes...

XBPS did compile and run fine for me locally.

[Johnnynator]

@Johnnynator we could use alternatives for the openssl command, and then use the specific impl cmd, i.e for openssl "openssl", for libressl "openssl-libressl" or whatever.

Probably the most sane way, I will prepare it like that.

@Johnnynator cool! I'll update the README then.

So I'm not against it, but what bothers me about openssl is the perl build dependency... it DOES matter while bootstrapping. I would take the alpine patch to get rid of it.

Alpine also needs perl for bootstraping, and the perl c_rehash runtime script is not needed in our case, since our ca-certifcates package is not using it, so we can simply ignore it. Also as q66 pointed out, we already have a few packages that need perl for bootstrapping (e.g. glibc, gcc), so I don't see an issue with OpenSSL needing it.

[Johnnynator]

Anyways, stick with libressl 3.1 for now, it's about to get released and adds more compatibility for openssl 1.1.

There are still significant gaps in the API.

[travankor]

stuff that uses libtls will need libressl, too

[q66]

Perl does not matter while bootstrapping, stop insisting that it does. I still don't see any reason to package both of them either, as @Johnnynator said it would require libarchive to be built against it and complicate everything. The "just in case" argument doesn't make any sense, either of them could mess up something and you have no way to know which.

[q66]

Does anything actually use libtls? Since it's a libressl specific api and most distros don't package it at all, I don't think we need to worry

[q66]

It is, since coreutils needs it, as well as GCC.

[q66]

Libcrypto contains the majority of the asm acceleration code, including for sha*. Wrt libtls: so... other openbsd projects (duh) - I doubt it'd required, as e.g. Debian packages openntpd without libressl, and s6-networking, which can also use bearssl, which is a better choice either way.

[q66]

Anyway, openssl needs Perl for good reasons, it uses it to deal with processing the assembly code for different targets. Libressl was only able to rip it out because they ripped out the asm

[q66]

C implementation of what?

[Johnnynator]

They still have c implementation of c_rehash but as I said, it is not really needed and we can ignore it, since we use the debian ca_certificates update script.

[q66]

There are much worse bootstrap dependencies we could have than Perl anyway, as far as I know Perl has never been problematic on anything, has been around for decades and is completely portable. And pretty much every single distro out there ships it.

[q66]

1. that doesn't even matter for this topic, since Perl is a host dependency. 2) the cross-compiling logic at least for current Perl isn't even complicated. Past doesn't matter, at all. 3) I don't care how many commits you have

[Ypnose]

I'm no longer a package maintainer, but from an user perspective libressl is sometimes painful when specific openssl options are needed and not included. There is an example here : libressl/portable#544
If it can save maintainers time, go for it.

[mobinmob]

[juan@leysa ~]$ xbps-query -Rs libtls.so -p shlib-requires
acme-client-0.1.16_4: libtls.so.19 (/mnt/storage/hostdir/binpkgs)
libressl-3.0.2_2: libtls.so.19 (/mnt/storage/hostdir/binpkgs)
libressl-netcat-3.0.2_2: libtls.so.19 (/mnt/storage/hostdir/binpkgs)
openntpd-6.2p3_5: libtls.so.19 (/mnt/storage/hostdir/binpkgs)
s6-networking-2.3.1.2_1: libtls.so.19 (/mnt/storage/hostdir/binpkgs)
[juan@leysa ~]$

s6-networking works with bearssl. Upstream marks bearssl support as beta but both Alpine and Adelie use it.

[howtologinquickwiththirtyninecharacters]

@Johnnynator you may want to update your package to 1.1.1g, versions d, e and f are affected by this vulnerability. (Is this the right place to comment on this or should I have commented on the New package request? I'm still new to this).

[Hoshpak]

The version remark would have been better in the PR however the vulnerability itself is highly relevant to this discussion since the number of vulnerabilities in each library is an important decision criterion for a TLS library.

[q66]

All software has vulnerabilities. I seriously doubt libressl has fewer of them.

[fosslinux]

This link shows that LibreSSL has more development than https://cpp.libhunt.com/compare-openssl-vs-libressl

Untrue, look at commit histories.

In this old link, it compares OpenSSL vs LibreSSL, showing how security is applied in LibreSSL code.
https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/
OpenSSL has a design problem, it is susceptible to serious flaws

(emphasis mine); yes, it is old, and that's the problem. OpenSSL's codebase quality and security auditing has increased greatly in the last 5 years. I would have agreed with you some time ago. Nowdays, LibreSSL gets much less auditing, has much fewer developers working on LibreSSL-portable, and has far less architecture support.

quantity of developers in OpenSSL does not mean quality in the code

I agree, but it does mean that something has to lose attention. Often, this is performance, or architecture support, and even build support/code quality (especially in libressl-portable), as @q66 can attest to.

OpenSSL has a lot of legacy OS discontinued

Care to elaborate?

[bugcrazy]

This link shows that LibreSSL has more development than https://cpp.libhunt.com/compare-openssl-vs-libressl

Untrue, look at commit histories.

In this old link, it compares OpenSSL vs LibreSSL, showing how security is applied in LibreSSL code.
https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/
OpenSSL has a design problem, it is susceptible to serious flaws

(emphasis mine); yes, it is old, and that's the problem. OpenSSL's codebase quality and security auditing has increased greatly in the last 5 years. I would have agreed with you some time ago. Nowdays, LibreSSL gets much less auditing, has much fewer developers working on LibreSSL-portable, and has far less architecture support.

quantity of developers in OpenSSL does not mean quality in the code

I agree, but it does mean that something has to lose attention. Often, this is performance, or architecture support, and even build support/code quality (especially in libressl-portable), as @q66 can attest to.

OpenSSL has a lot of legacy OS discontinued

Care to elaborate?

LibreSSL has an independent audit, which can be seen on this link, with a report by a member of Void Linux.
https://blog.doyensec.com/2020/04/08/libressl-fuzzer.html

This academic thesis "Analysis of software vunerabilities through historical data" shows comparative graphs of CVEs. http://lup.lub.lu.se/student-papers/record/8923711/file/8923713.pdf

OpenSSlL has a bad design, which favors serious vulnerabilities, this has not been fixed, as this is part of the structural code of OpenSSL, over the years, it has maintained serious vulnerabilities that affect linking software.

https://news.ycombinator.com/item?id=22935221

openssl/openssl#4729

openssl/openssl#4733

https://hownot2code.com/2016/06/03/evaluate-the-string-literal-length-automatically/#more-172

https://www.viva64.com/en/b/0183/

In these links you can compare the number of CVEs between OpneSSL and LibreSSL.

https://www.cvedetails.com/vulnerability-list/vendor_id-217/Openssl.html

https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-30688/Openbsd-Libressl.html

[fosslinux]

CVEs are an interesting thing, and actually a point I brought up much earlier, I think on IRC, when I wasn't convinced of moving back to OpenSSL. Basically, OpenSSL is a far more audited codebase and receives more auditing attention than LibreSSL.

I don't see linters/static analysis code checking tools, alone, as evidence of poor coding practices. An OpenSSL dev said in one of those threads that many are false positives.

In addition, each of the articles you linked above (excluding the recent vuln, which was discussed earlier in this thread) are 3+ years old. Again, I am of the opinion that the code quality has improved in that time.

Anyway, I don't think I'll go back and forth, let others lay down their opinions on your data if they would like.

Thanks for the threads, btw, interesting reads, which do reinforce Void's position for originally changing to LibreSSL... at the time.

[concatime]

I would recommend:

1. changing xbps to bearssl. It has really straight API. One downside is that it does not support TLS 1.3 yet. It’s really easy to build/bootstrap, no perl nor cmake, just pure make.
2. replace LibreSSL by OpenSSL 1.1
3. drop all packages that require OpenSSL 1.0

LibreSSL is intended to be used in OpenBSD. I don’t even know if LibreSSL follows OpenSSL 1.0 or 1.1 API. I had a bug with OCSP in Nginx and it took them 8 months to fix it. See libressl/portable#532. LibreSSL is not a bad project at all, it’s just that it’s meant for OpenBSD.

[q66]

well, ideally we'd go straight with openssl 3.0; it should be out soon, AFAIK.

[fosslinux]

changing xbps to bearssl

Two ssl's is probably a recipe for disaster.

replace LibreSSL by OpenSSL 1.1
drop all packages that require OpenSSL 1.0

Agreed.

LibreSSL is not a bad project at all, it’s just that it’s meant for OpenBSD.

100% agree

[q66]

i think they meant making xbps use only bearssl, which would be fine - you already have multiple TLS implementations in your system (there's openssl/libressl, but also nss, gnutls, etc.)

bearssl is nice, small, and explicitly geared towards security (it performs no dynamic memory allocations for example, AFAIK)

[fosslinux]

Ah, I see.

[mgorny]

FYI Gentoo is discontinuing support in LibreSSL in February — however, in our case it's easier because LibreSSL was always the alternative option.

[marmeladema]

Nice read about this: https://lwn.net/SubscriberLink/841664/0ba4265680b9dadf/

[AngryPhantom]

Another (Gentoo) read is here.

P.S. Sorry, it can be already mentioned via link in the comment above.

[astralchan]

I don't really know too much about the fine details, but all I hope is that VOID might at least keep LibreSLL as an option? For me at least, LibreSLL was one of the main selling points of VOID.

[eli-schwartz]

There's no such thing as keeping it as an option. Every application that links to the ssl libraries needs to either link to one or the other. It's possible to have both, and for some programs to link to one and some to link to the other, but you cannot just swap them out.

If you want to have a version of Void Linux that uses libressl while the main version of Void uses openssl, then it does indeed need to be a version of the entire OS. It would be like the musl/glibc split.

[astralchan]

There's no such thing as keeping it as an option. Every application that links to the ssl libraries needs to either link to one or the other. It's possible to have both, and for some programs to link to one and some to link to the other, but you cannot just swap them out.

If you want to have a version of Void Linux that uses libressl while the main version of Void uses openssl, then it does indeed need to be a version of the entire OS. It would be like the musl/glibc split.

I see. It would increase the things to maintain to:
VOID
VOID-musl
VOID-LibreSSL
VOID-LibreSSL-musl
then.

[eli-schwartz]

More or less.

Some packages could be shared between openssl and libressl spins (if they don't link to libssl.so and friends) but it would be less effort to rebuild everything anyway I'm guessing.

[ericonr]

Most of the listed pros in the top post lead to a decrease in the maintenance burden related to the library that provides the "OpenSSL API" (LibreSSL's ABI breaks, patching external software, etc). If someone wishes to maintain a void-libressl distro after such a switch has happened, I can't see it being anything but a Void fork.

[mikhailnov]

It's possible to have both, and for some programs to link to one and some to link to the other

Only for some. It will lead to mixture of 2 different libssls in one runtime in many cases.

[Logarithmus]

How do libressl & openssl compare in terms of code lines count?
Also isn't libressl source code better? Or did the matters change since 2014?

If I understood correctly, the main reason to abandon libressl is maintainance burden. OK, then why support musl then?
I use musl myself because it's lightweight & its source code is easy to read, compared to glibc. But unfortunately it seems that majority of developers don't care about POSIX compliance at all. IMHO musl patches are PITA much more than libressl.

[ericonr]

If I understood correctly, the main reason to abandon libressl is maintainance burden. OK, then why support musl then?
I use musl myself because it's lightweight & its source code is easy to read, compared to glibc. But unfortunately it seems that majority of developers don't care about POSIX compliance at all. IMHO musl patches are PITA much more than libressl.

C standard libraries have a standard to follow (POSIX, SUS, whatever BSD extensions), however loosely, which makes them at least somewhat homogeneous. musl also considerably affects the entirety of the resulting system: lower memory footprint, less dependency on arbitrary config files spread throughout the file system, and better resilience towards resource exhaustion. On 32-bit systems it also provides y2038 support, once we update that :p

LibreSSL and OpenSSL implement an "arbitrary" API, with obscure versioning and extremely weird usage, and using LibreSSL has removed functionality from many packages we ship.

[dm17]

LibreSSL is not a bad project at all, it’s just that it’s meant for OpenBSD.

100% agree

I can think of another option... What if we reached out to Hyperbola, KISS Linux, Gentoo, and others - to see how many might want to contribute to a LibreSSL port done right for Linux. Just promote it as a potential project so it can be seen... And then no harm no foul if it doesn't get enough support?

The conclusions in this thread make sense, but one thing that is left out is the free potential of organizing interested & motivated parties.

[Vaelatern]

@dm17 , you are welcome to spend your effort on this approach. Void is unlikely to switch back, since that is additional effort as well.

[mgorny]

@dm17, the problem is not "port done wrong". The problem is lack of compatibility and lack of interest upstream to maintain compatibility with two similar-but-incompatible libraries.

[bugcrazy]

@dm17, the problem is that corporations dominate mainstream software, they don't want plurality, they like to centralize, to force the use of software monoculture. There are problems with the Libressl team forcing only on OpenBSD, but on the other hand in the Linux world, there is no unity and innovation on the part of the community, what there is are corporations dictating the rules, what goes in and out of the distros!

[Duncaen]

We are still waiting on our paychecks, but the switch back to openssl was finalized and there is no need to further discuss this.