Hacker News Reader

Comment by jillesvangurp | Hacker News Reader

I'm curious to know why they switched back to openssl from libressl. Are there compatibility issues or have the issues that caused libressl to be created been addressed now in openssl?

View on HN

This post[0] contains some of the reasons:

  - better upstream support from projects 
  - To my understanding, various of the issues in OpenSSL
    that made us switch to libressl have been resolved.
    (for example memory management) 
  - libressl failed to retain compability with OpenSSL 
  - libressl breaks ABI every 6 months, OpenSSL does not 
  - FIPS support

[0]:http://lists.alpinelinux.org/alpine-devel/6308.html

A more organic reasoning about it here: http://lists.alpinelinux.org/alpine-devel/6073.html

It sounds weird that FIPS is relevant to Alpine. They're not going through the certification process, so does it matter?

There are situations where you want to be able to say you're using a FIPS certified crypto library, but that you're not going to get the whole thing certified.

I went through that with an IBM product I was working on years ago. It involved taking out any crypto implementations already in the code (I believe we had a reference DES implementation doing something with passwords) and switching to FIPS certified TLS libs. At the end we got to say we were FIPS compliant (NOT certified), which was important for some government contract or other.

Also interesting is that the PCI SSC is now recommending FIPS 140-2. While not likely relevant to the decision in Alpine, it may be relevant downstream with regard to choosing Alpine to develop on.

PCI Standards Security Council - Secure Software Standards v1.0 (Jan 2019) https://www.pcisecuritystandards.org/document_library?catego...

Oh interesting. That said I've only ever taken devices through PCI-PTS, not worked on PCI compliant software so I have no idea how much of a departure this is from common practice.

The one thing that would concern me about widespread adoption of FIPS-certified tech is that (IIRC) FIPS 140-2 essentially forbids PFS modes (DH/DHE) on TLS, presumably for traffic audit purposes in secure government environments.

OpenSSL is the de facto industry standard.

To me this list explains why one should stick to OpenSSL.

That logic might hold for a container platform meant to run other peoples code, but it’s one of the best reasons to not use it in other contexts like load balancers.

My logic is that you probably want a proven, up-to-date crypto/TLS library with a 'standard' API whatever the application.

I thought heartbleed proved this appeal to authority wrong causing liressl to exist in the first place.

OpenSSL is continuously scrutinised and has resources and pressure to fix issues.

A less ubiquitous library is not as scrutinised (so who knows what vulnerabilities lie within?) and has probably not the same resources/pressure to fix.

Forks are often political before anything else.

Fragmentation is not a good thing.

I’m not suggesting you fork it yourself, write your own, or use Joe Schmoe’s SSL library. There are other major implementations such as Amazon’s s2n that have many eyeballs on them daily.

Diversity of infrastructure components confers similar resistance as DNA diversity in the wild.

https://github.com/awslabs/s2n

Go use OpenSSL, see the absolutely horrendous API and then come back and see if you recommend it.

I'll add I saw a number of Docker image discussions where people asked about TLS 1.3 support, and the answer was "blocked in Alpine, which is blocked in Libressl".

From what I understand, libressl was a fork of openssl resulting from a bunch of people who were pissed about heartbleed. Not being so dependent on one library is good, but that doesn't necessarily mean that the alternatives are better. Openssl is still more established, and from what I understand (anecdotally), openssl is faster (an important consideration for a distro like alpine). With that said, libressl is likely more secure (which means it may be an option to go along with alpine's hardened kernel).

https://en.wikipedia.org/wiki/LibreSSL

Nice to see someone go "lets choose the faster lib over the more secure one" for a security lib. No way that could ever go wrong in the long run. Or if it already did.

Not commenting on the choice from alpine, just comment on this post.

Reply on news.ycombinator.com