6 ms·
This post[0] contains some of the reasons: - better upstream support from projects - To my understanding, various of the issues in OpenSSL that made u
by _ikke_ 8y ago
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 http://lists.alpinelinux.org/alpine-devel/6308.html
- izietto 8y agoA more organic reasoning about it here: http://lists.alpinelinux.org/alpine-devel/6073.html http://lists.alpinelinux.org/alpine-devel/6073.html
- viraptor 8y agoIt sounds weird that FIPS is relevant to Alpine. They're not going through the certification process, so does it matter?
- Nursie 8y agoThere 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.
- windexh8er 8y agoAlso 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?category=sware_sec#results https://www.pcisecuritystandards.org/document_library?catego...
- Nursie 8y agoOh 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.
- entity345 8y agoOpenSSL is the de facto industry standard. To me this list explains why one should stick to OpenSSL.
- koolba 8y agoThat 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.
- entity345 8y agoMy logic is that you probably want a proven, up-to-date crypto/TLS library with a 'standard' API whatever the application.
- jeremycw 8y agoI thought heartbleed proved this appeal to authority wrong causing liressl to exist in the first place.
- entity345 8y agoOpenSSL 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.
- koolba 8y agoI’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 https://github.com/awslabs/s2n
- 8y ago
- technion 8y agoI'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".