Hacker News Reader

Comment by VeejayRampay | Hacker News Reader

And that's not even the worst of it all in my opinion. What really struck me in the midst of that whole debacle was the number of programming-geniuses-in-hindsight.

OpenSSL is a free software project, meaning that everyone smart enough to snark after the fact could and should have been providing patches before all hell broke loose. I mean, it is amazing how many people were poking fun at the "awful coding practices" and the "bug-laced codebase". Where were all those people when the code was committed?

There's no winning in a culture where you devote your time and efforts for the greater good in an extremely complicated field of computer science only to be lambasted at the first mistake by the very same people who should have steadying the boat with you in the first place.

View on HN

  > everyone smart enough to snark after the fact could and
  > should have been providing patches before all hell broke
  > loose.

Could have? Sure. Should have? Not so fast. Quite a few of those people had pointed out that the complexity and sheer ugliness of the OpenSSL code created a large unnecessary barrier to contribution, and that people's time would be better spent on alternatives. It would be very interesting to look at the use:contribution ratios over time for OpenSSL and e.g. PolarSSL, which also happens to be GPL-licensed. Sometimes the people who made a mess bear primary responsibility for cleaning up, and there's nothing wrong with others saying so. Bringing pressure to bear on the people who can actually make that kind of fundamental change might be more productive than submitting patches that have to be rejected because they're based on wrong assumptions about complex code.

Now, if someone from one of those freeloading companies that have eschewed alternatives and continue to ship millions of copies of OpenSSL without contributing anything were to offer such criticism, that would be wrong. It would be wrong not because it's kibitzing from an outsider, but because it's ingratitude from an insider. That's a different thing. If contribution was always a precondition for comment, this would be a very quiet world. Comments like these might not be allowed:

  > this is excruciating to read due to very strange page
  > layout.

Where's the patch for that?

I have nothing more to add to that except that what you just said indeed adds more nuance and I totally agree.

And touché (though I guess you nothed I merely criticized the form and thanked the author for the content) :)

Many said this in hindsight, but for OpenSSL it was no lack of people that said this in foresight as well, i.e. they complained about the shoddy code quality of OpenSSL long before the heartbleed attack. One of those was Poul Henning Kamp, that have mentioned OpenSSL as a problem in many talks before Heartbleed was discovered. He is not alone. It is also quite well known that OpenSSL have had a unusually high number vulnerabilities in its history, mostly because its low quality. I have read the code, even before the heartbleed bug was introduced, and I was not surprised that this could happen. Some of the code that lead to the heartbleed bug was made to bypass security measures done by the operating systems to make it hard to exploit such vulnerabilities, and the maintainers did this instead of fixing the problem.

So why have nobody fixed them. I guess one of the reason is that the codebase is broken beyond repair, and it was not just to "provide patches". In fact a major rewrite or reworking of the code was required, and this is what the people behind LibreSSL currently are doing.

Another reason is that people (and companies) generally are not willing to pay for security, and does not know when something is secure or not. Thus for something that works, but is insecure, the incentive for doing something about it is missing. Security vulnerabilities is only theoretical for most people.

It's been linked by me (and others) at times, but PHK's recent talk at FOSDEM[1] is something every engineer needs to see. In the talk, he not only has a well-reasoned warning about OpenSSL months before Hearbleed, but he makes a pretty convincing argument about the "PSYOPS For Nerds" we could be witnessing in this very thread.

Are the nerds about to fix some of the security holes you've been exploiting? Easy; just distract them with yet another "gpl vs bsd" bikeshed argument! They never get tired of it!

[1] http://video.fosdem.org/2014/Janson/Sunday/NSA_operation_ORC...

Perhaps we need to take a second look at where the "lambasting" first took place. It was well, well before this recent OpenSSL incident.

For many years now, the security community taken as a whole has very vocally stated, "Never roll your own crypto!", and been highly critical of anyone who has attempted to do so without the security community's blessing.

For many programmers, maybe that is good advice. They probably shouldn't try to design their own schemes, and probably shouldn't try to build them, either.

But I think this attitude has also driven away a lot of very talented programmers who perhaps could have caught an issue like this much earlier on, or perhaps even avoided it in the first place.

So I believe it's misleading for you to portray the users of OpenSSL as somehow being responsible, especially given how much effort the security community has generally put forth toward discouraging more direct participation from these users.

The security community took a holier-than-thou attitude for a long time. It has now been shown that they aren't necessarily any better at avoiding critical and very harmful bugs in their code, however. So of course people will call them out. And there's not a thing wrong with doing so.

Wait a minute, does OpenSSL === The Security Community? It's an honest question because I really don't know who is behind OpenSSL and what their standing is in the security community.

That said, your final sentence seems unfair either way. The warning not to roll your own crypto is to avoid the all too common noob pitfalls whereby a reasonably experienced developer invents a security scheme that is completely and utterly broken from its very conception. It's not tell smart people they are too stupid to do crypto (which is a lot of programmers' knee-jerk reaction to being accused of ignorance on any technical topic), it's merely to point out that there's a lot of existing knowledge out there about crypto, and if you don't go learn about it first then your contribution will almost certainly be of negative value.

It's not meant to say don't contribute to OpenSSL or one of its competing libraries, it's meant to say that you need to be grounded in the state of the art and have peer review in order to produce a solid cryptography product.

I got the same vibe from the chorus of "never roll your own crypto" rhetoric I heard on the Internet -- that I shouldn't even bother looking into OpenSSL's code unless I went to the Shaolin Temple of Crypto and trained under Master Schneier for 10 years. Just because the intent of the message was one thing doesn't mean that it won't be interpreted in a completely different way by the intended audience.

Looking at OpenSSL source code and fixing a bug are pretty much the exact opposite of "rolling your own crypto."

The impression I got from "don't roll your own crypto" (especially after the Debian key bug thing) was that crypto code was so nuanced and complicated that even if you thought something was a bug, you were likely to be horribly wrong for really complex reasons outside the realm of understanding of anyone who wasn't an expert, and everyone would laugh at you for even bringing it up.

After an entire webpage was created to ridicule the Debian developers for how stupid they were when they changed something in OpenSSL's code in their distro's version (complete with references to Dilbert strips about faulty random number generators), I just assumed that I shouldn't even bother trying to look at OpenSSL's code (and especially not try to send patches or ask questions on their mailing list) unless I was willing to make a lifestyle out of it, lest I get ridiculed in the same way (but probably not at Debian's magnitude). I wasn't willing to make a lifestyle out of it.

Obviously a lot of security people and cryptographers develop a holier-than-thou attitude, no doubt from spending their lives scrutinizing things that people continuously get wrong and for which failure is catastrophic.

That attitude, off-putting though it may be, shouldn't cause us to read too much into what they say.

> OpenSSL is a free software project, meaning that everyone smart enough to snark after the fact could and should have been providing patches

If you follow Valhalla, OpenBSD merged a number of patches which had been languishing in the OpenSSL tracker for months or years.

The OpenSSL license is a little strange, which may have pushed away potential contributors.

I have two conflicting moods here.

First, companies using OpenSSL for free were completely living up to their end of the bargain, which was "you can use this for free."

Second, there was absolutely nothing stopping a few banks and/or giant web companies from getting together to raise a million dollars to have this code professionally audited. Banks do spend lots of resources auditing the code they write themselves, so how come nothing was spent here?

(Related to second point: There was also absolutely nothing was stopping people from doing what the OpenBSD team is doing now and deciding to tear it apart to clean it up. There was also absolutely nothing forcing people to use OpenSSL. )

... Or OoenBSD.

But it looks like until recently there was not sufficient funding to retain said developers, so you're restricted to the subset of developers who have a particular interest in openssl.

Hang on a second tho'. What sort of warped design process came up with the idea that a "ping" should be up to 64k in length? That's so far off the wall it's not even wrong (Feynmann). Whoever came up with that idea is the one at fault...

"Not even wrong" is something W. Pauli said first, although Feynman might have quoted him.

IPv4 ICMP echo request/response packets can be 64k in length.

Reply on news.ycombinator.com