4 ms·

It's remarkably hard to find any recent discussions if libressl is ready for production. A comparison on https://en.wikipedia.org/wiki/LibreSSL https://en.wiki

It's remarkably hard to find any recent discussions if libressl is ready for production. A comparison on https://en.wikipedia.org/wiki/LibreSSL https://en.wikipedia.org/wiki/LibreSSL seems to indicate libressl is less vulnerable.

epimenov 11y ago
/ sw_vers ProductName: Mac OS X ProductVersion: 10.11 BuildVersion: 15A282a / /usr/bin/ssh -V OpenSSH_6.9p1, LibreSSL 2.1.7 I guess it is ready for production
- Beltiras 11y ago
  Apple is one vendor and I don't care much for their OS.
deleted 11y ago
[deleted]
- protomyth 11y ago
  What does OpenSSL do in that situation?
  - sarciszewski 11y ago
    It doesn't matter. I give up.
ben_bai 11y ago
OpenBSD uses it from the beginning. The portable Version should have some testing on it as well. Yes, it's production ready. as always YMMV.
paulmd 11y ago
If you're looking for a guarantee - very few non-trivial programs are provably correct. Heck, most of the time what comes out of the compiler isn't even exactly what you put in - everyone knows -O3 can do some weird stuff, and that's A Bad Thing in certain kinds of software. We're only just starting to break that ground now with verifying compilers like CompCert (which can output a set of mathematical proofs that your program is correct for the given input). I'm not involved in it but I find that niche to be really interesting, along with reproducible builds. It's crazy that nobody bothered with simple stuff like "seeding the PRNG for stochastic optimizers". You'd have thought they'd just pick a reasonable default. So given that we live in a world of imperfect code, it's a question of what's least-bad. OpenSSL is known to be a horrific mess of crufty under-maintained code, which is a big part of why it keeps having major security breaches. Like this article points out - nobody has bothered to compile this option for more than a decade. Options lead to internal complexity which leads to crap code that nobody can/will maintain, which is the wrong path for security-critical software. If nobody uses it then get rid of it - if someone wants it they can dig it out of revision history. The OpenBSD folks are happy enough with LibreSSL that they released it with OpenBSD 5.6, which is good enough for me. I'm sure there's some esoteric vulnerabilities lurking and maybe the cleanup introduced a few new ones, that's just the nature of non-trivial software. But in the big picture I just can't see it as being any more vulnerable than OpenSSL, and that seems to have been borne out in their respective track records recently.
- Beltiras 11y ago
  I'm not naive. All software has bugs. Only thing that works out the bugs is battle testing. I was just wondering if LibreSSL was battle tested enough to use in production.
  - structural 11y ago
    Battle testing finds uncommon bugs. This is orthogonal to whether these bugs are security-relevant. See, for example, shellshock, which was in a piece of software that's been battletested by most people who use a command-line for the past, oh, twenty years or so. Whether or not the developers actually know what they're doing with respect to writing secure software in the language of the project and are sufficiently OCD in their process to catch most mistakes before they reach production is very, very much more important than "battle tested for X number of years".
technion 11y ago
That depends on your goals. I started testing nginx compiled against LibreSSL from before portable was official[0]. If your goal is security, as far as I'm concerned it's met that goal since day one. If the goal is stability, the slimmer codebase is certainly no less stable than OpenSSL. There were however, several occasions places where code didn't compile for various reasons. Some were fixed by nginx, and some were fixed with PRs I sent LibreSSL. Key to this is that there were situations where newer releases of LibreSSL broke my build process. If you were on a project less ubiquitous than nginx, you may find that sort of hacking a waste of time. If you have the resources to use it, it's posts like this that strongly turn me in the direction of LibreSSL. [0] https://github.com/technion/libressl_nginx https://github.com/technion/libressl_nginx

epimenov 11y ago

/ sw_vers ProductName: Mac OS X ProductVersion: 10.11 BuildVersion: 15A282a / /usr/bin/ssh -V OpenSSH_6.9p1, LibreSSL 2.1.7 I guess it is ready for production

Beltiras 11y ago
Apple is one vendor and I don't care much for their OS.

deleted 11y ago

[deleted]

protomyth 11y ago
What does OpenSSL do in that situation?
- sarciszewski 11y ago
  It doesn't matter. I give up.

ben_bai 11y ago

OpenBSD uses it from the beginning. The portable Version should have some testing on it as well. Yes, it's production ready. as always YMMV.

paulmd 11y ago

If you're looking for a guarantee - very few non-trivial programs are provably correct. Heck, most of the time what comes out of the compiler isn't even exactly what you put in - everyone knows -O3 can do some weird stuff, and that's A Bad Thing in certain kinds of software. We're only just starting to break that ground now with verifying compilers like CompCert (which can output a set of mathematical proofs that your program is correct for the given input). I'm not involved in it but I find that niche to be really interesting, along with reproducible builds. It's crazy that nobody bothered with simple stuff like "seeding the PRNG for stochastic optimizers". You'd have thought they'd just pick a reasonable default. So given that we live in a world of imperfect code, it's a question of what's least-bad. OpenSSL is known to be a horrific mess of crufty under-maintained code, which is a big part of why it keeps having major security breaches. Like this article points out - nobody has bothered to compile this option for more than a decade. Options lead to internal complexity which leads to crap code that nobody can/will maintain, which is the wrong path for security-critical software. If nobody uses it then get rid of it - if someone wants it they can dig it out of revision history. The OpenBSD folks are happy enough with LibreSSL that they released it with OpenBSD 5.6, which is good enough for me. I'm sure there's some esoteric vulnerabilities lurking and maybe the cleanup introduced a few new ones, that's just the nature of non-trivial software. But in the big picture I just can't see it as being any more vulnerable than OpenSSL, and that seems to have been borne out in their respective track records recently.

Beltiras 11y ago
I'm not naive. All software has bugs. Only thing that works out the bugs is battle testing. I was just wondering if LibreSSL was battle tested enough to use in production.
- structural 11y ago
  Battle testing finds uncommon bugs. This is orthogonal to whether these bugs are security-relevant. See, for example, shellshock, which was in a piece of software that's been battletested by most people who use a command-line for the past, oh, twenty years or so. Whether or not the developers actually know what they're doing with respect to writing secure software in the language of the project and are sufficiently OCD in their process to catch most mistakes before they reach production is very, very much more important than "battle tested for X number of years".

technion 11y ago

That depends on your goals. I started testing nginx compiled against LibreSSL from before portable was official[0]. If your goal is security, as far as I'm concerned it's met that goal since day one. If the goal is stability, the slimmer codebase is certainly no less stable than OpenSSL. There were however, several occasions places where code didn't compile for various reasons. Some were fixed by nginx, and some were fixed with PRs I sent LibreSSL. Key to this is that there were situations where newer releases of LibreSSL broke my build process. If you were on a project less ubiquitous than nginx, you may find that sort of hacking a waste of time. If you have the resources to use it, it's posts like this that strongly turn me in the direction of LibreSSL. [0] https://github.com/technion/libressl_nginx https://github.com/technion/libressl_nginx