A tale of software maintenance: OpenSSL and EVP_CHECK_DES_KEY | Hacker News Reader

A tale of software maintenance: OpenSSL and EVP_CHECK_DES_KEY

marc.info

110 pointsPhantomGremlin21 comments

Ugh, another example of why conditional compilation is such a bad idea. I know, I know, sometimes it's inevitable. But if you're going to use it, you'd better be ready to set up a build farm that regularly compiles your code with every possible permutation of compiler flags, otherwise your code is guaranteed to break in unexpected ways.

The LibreSSL solution is the correct one here: if your code is old and unused, just delete it ffs. The argument that "we might still need it in the future!" is such a lame one. No you don't, and even if you do it'll be easier to just rewrite it than to try and make years-old code work in a modern environment. In the meantime you've only succeeded at cluttering your code with garbage that has no relevance whatsoever.

>The LibreSSL solution is the correct one here: if your code is old and unused, just delete it ffs.

I sort of suspect that the OpenSSL developer just fixed the compilation error, because it's actually easier than deleting code completely.

If you need old code, browse through the repo and find it.

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

  /  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

Apple is one vendor and I don't care much for their OS.

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.

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.

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.

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

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

2 things:

1) 11 years. The code in question was 11 years old. Another example not to rely on "given enough eyeballs, all bugs are shallow". 11 freakin years.

2) Security off by default is yet another example indicating how security receives lower priority - in a library whose main aim is to secure data transport no less!

It all adds up to security debt - at some point it will be paid.

Off by default was the correct choice.

A PRNG debian bad? I remember the ssh keys incident years ago (that was indeed ridiculouts, but shit happens).

But I don't remember any new facts about debian weakening PRNG since.

PS: Ok, I also missed debian infortunately also weakening the openSSL PRNG until 2008.

The random data that was used to initalize the PRNG was removed as it was causing a linting error and only the PID was used meaning there were only 32768 (2^15) initial states that the PRNG would be seeded with.

https://www.schneier.com/blog/archives/2008/05/random_number...

Yes I remembered this one, and this resulted in the SSH keys being weakened. So ... it is the same incident.

OpenBSD could forgot one day. As if 50 core devs pretending to know their jobs could do better than 10000 devs with tremenduous amounts of guidelines and administrative rules and a fair amount of political commissars.

Lol. Bureaucracy will always beat amateurs.

Weakened? It meant it would only generate a couple of thousand keys, that's not weakened, that means security was killed completely. And it was in there for a couple of years. All in all a total fiasco and legendary for very good reasons.

Trying to paper over it and pretending it was no big deal is the best way to ensure that similar things will happen again.

That's a hilarious write-up. The OpenSSL anecdote? Less so. Another dark tale in the history of software "maintenance" and the C language.

"<drops mic; walks off stage>"

Very funny way of writing ... Thank you so much for this :D

Reply on news.ycombinator.com