Hacker News Reader

Comment by _ikke_ | Hacker News Reader

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

View on HN

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".

Reply on news.ycombinator.com