OpenSSL Security Advisory | Hacker News Reader

OpenSSL Security Advisory

openssl.org

32 pointscremno9 comments

[CVE-2014-3505] was reported to OpenSSL on 6th June 2014.

[CVE-2014-3506] was reported to OpenSSL on 6th June 2014.

[CVE-2014-3507] was reported to OpenSSL on 6th June 2014.

Holy crap. That's 3 bugs (out of 9) that waited 2 months before a fix was released, one of which (CVE-2014-3505) is a double-free crasher.

Here was me thinking/hoping that the devs had actually meant it when they said they were doing to get on top of this stuff after Heartbleed.

I guess not.

Do you want your money back?

I want people who aren't up to providing secure security software to say so and bow out, rather than giving their users a false sense of security, and giving other developers a reason for not wanting to create "unnecessary" forks and split mindshare/effort in the hopes that OpenSSL will be "good enough".

There's still not as much effort going into the alternatives as there could be, because people are still hoping that OpenSSL will get its act together, and that downstream devs won't have to start writing autotool magic and #ifdefs to deal with OpenSSL and LibReSSL and GnuTLS's OpenSSL wrapper and whatever other fork(s) their users might be using instead.

I think if OpenSSL got out of the way, we'd converge on a better replacement more quickly than we are doing now, and we'd all be more secure as a result.

Classic Dunning-Kruger effect. The OpenSSL people don't realize how incompetent they are.

One day there'll be a study on the types of people that cite the Dunning-Kruger effect.

From a notice sent by the OpenSSL team to internal groups:

"Since these security defects are considered as moderate severity or less no further details or patches will be made available in advance of the release..."

So waiting 2 months for something that is not critical is no reason to start acting like the sky is falling.

God damn it not again. Bring on boringssl/libressl. Although they'll be full of holes as well probably, and as things stand there's a lot of people looking at openssl at the moment. So maybe better the devil you know

The forks might not be quite so full of holes.

The LibReSSL folks removed the whole SRP module from their tree recently[0] because an embargo that prevented them from releasing just a bugfix in what they thought was a reasonable timeframe. I'm guessing that was for either CVE-2014-5139 or CVE-2014-3512.

That does actually give me some confidence that some of the other non-OpenSSL dev teams might do measurably better.

[0] https://news.ycombinator.com/item?id=8105373

Trouble is, so much has changed that they need a whole separate audit. And who knows what problems removing code introduces. But then again, they might not b worse, but they'll still need auditing to find out

Reply on news.ycombinator.com