Surely, Nigel, if you'd just implemented your own encrypted transport, everything would have worked out great. Look how well that worked for Cryptocat.
The most consistent complaint about OpenSSL is that it is developed amateurishly (I think it's more complicated than that, but "amateurish" is a fair summary of the critique). Your response seems to be, "double down on amateurish!"
PS: The only reason you know about heartbleed is that one of the self-proclaimed "experts" found it for you. Neel Mehta is an insider's insider.
Heartbleed, and "goto fail" are bugs that any competent C developer could have found. You, me, the muffin man, the NSA, a bright undergraduate student. Anyone. These aren't vulnerabilities that you read about in a crypto journal. They are basic implementation bugs.
So why weren't they found by amateurs? (Well, perhaps the premise is false. Perhaps they were found by amateur attackers.) However I submit to you if true it is because people who are actually experts in cryptography do not generally spend their time looking for dumb implementation bugs. I'm sure some do, but many don't. Which is understandable--we want those people looking for weaknesses in AES or curve25519 or something.
Meanwhile we have a culture of abstinence-only crypto education, where everything crypto touches is a forbidden land that we shame any ordinary software developer for venturing into. Nobody found this bug because ordinary developers aren't there to find it. They're not there because they're told to leave.
You suggest "double down on amateurish" facetiously but I claim that amateur hour would have actually caught these two bugs, because any amateur can see them. Maybe it would have created more bugs, maybe not, but I think it would have stopped these two early.
What I think we need to do, and what we should have done a long time ago, is recognize that abstinence-only crypyotgraphy doesn't work. We need to define levels of risk. Writing your own crypto algorithm is Threat Level Red. Implementing a strong one from a spec is Threat Level Yellow. Implementing a high-level authentication scheme like TLS from a spec is Threat Level Green. Porting OpenSSL to a new architecture is Threat Level Blue.
Abstinence-only crypto education doesn't recognize that some people are going to do crypto anyway. It also doesn't recognize that "not enough eyes" is a threat model that objectively produces THE most serious vulnerabilities we have faced in recent years. Putting all our eggs in OpenSSL and telling ordinary developers to use it and not ask questions literally burned down the internet. I don't know what kind of bad scenario we were trying to avoid, but the one that actually happened was worse.
Some type of risk-aware model encourages people to get involved in a skill-appropriate way. That needs to be the goal of the crypto community right now; to capture the energy from software developers interested in cryptography (particularly due to recent world events) and do something useful with it; not turn them away and say "nothing to see here".
"Not enough eyes"? OpenSSL is among the most aggressively reviewed codebases in the industry. Everyone reads OpenSSL. The problem with OpenSSL isn't that it didn't get "enough eyes". The problem is that the code is bad. It's disorganized, serves too many interests, and (particularly in the TLS portion of the tree) is a grab bag of functionality.
OpenSSL implements twenty two TLS extensions. NSS, the library used by Firefox and Chrome, implements 11. Why was it possible for some dude in Germany to specify a TLS extension that nobody really needed and then implement it in OpenSSL as the client default? Because OpenSSL is a bazaar, not a cathedral, and nobody really claims ownership of what the code in openssl-1.0.1e/ssl is supposed to do.
Also: check your availability bias. "Burned down the Internet"? This was a bad bug, but it wasn't unique; nginx had the same bug just a couple years ago (I know this because we found it). But shove all that aside, because these are all codebases that have hosted remote code execution flaws.
This is a cross-vendor, cross-platform vulnerability that requires one to assume that almost any password used over https, any SSL session, or almost any SSL certificate used in the last year, hell, anything in server memory in the last year is compromised. I'm quite confident there are many systems that relied solely on SSL to gate immediate, root access, and some of those are still right now, as we speak, exploitable.
If that's not "burned down the internet" nothing possibly qualifies.
Anyone would say you stand to benefit from security remaining some sort of priesthood activity or something.
Diversity of implementations is a good thing, for the simple reason the number of people an individual vulnerability could expose would be that much smaller.
People have weird ideas of how we stand to benefit from things. Check out http://matasano.com/careers for a comprehensive rebuttal.
Diversity of SSL implementations is a complicated proposition. When the Bleichenbacher e=3 attack happened, the monoculture helped: the most popular TLS clientsides weren't vulnerable, but the oddballs were. When research labs fuzz X.509, they find X.509 parsing bugs in the oddball libraries, not in OpenSSL.
Be careful, because you're operating from a pretty serious availability bias. You vividly remember this recent vulnerability, because the researchers did a great job of publicizing it. But this isn't the worst vulnerability that's been found, even in TLS stacks, by far.
Computer security is like a genepool, and you can breed the strongest most brilliant thing you want in it, but when you cut down on diversity and then encounter some new virus that wipes everyone out, what happens?
Diversity alone does not solve the situation, you need a diversity of competent products, but having one loudly supported implementation that isn't nearly as good as people are led to believe is epicly stupid.
The fact so many people know that OpenSSL is a disaster area is even more damning for the security industry. Yes, Google are paying people to fix it at the edges, but it's clear from the likes of TdR that their whole process is broken, and yet in all the time it's been visibly broken to many of your insiders very little has been done to attempt to fix the structural problems, and a lot of effort has been made to shout loudly about how difficult fixing them would be, putting off anyone that might be trying to help. It's nonsense.
This is time for a bit of humility from the security industry, not for strutting around proudly.
There are no testable assertions in your comment, nor any specific facts. I took the time to respond to your comment with citations to previous vulnerabilities and assertions about the impact of "monocultures" on them.
It's a little uncharitable of me to say this, but: I anticipate you won't actually respond to those assertions. So I guess I'd then ask: who has the more trustworthy argument? The person appealing to emotion and sinister (and, in this specific case, silly) motives, or the person who can refute an argument with specific examples?
If you think OpenSSL is "damning" of the whole "security industry" (whatever that is), you are of course welcome to start your own "security industry". If you can find the kinds of things "priests" like Neel Mehta can, I assure you, you'll be richly rewarded.
If we had multiple equally used SSL implementations of equal quality and used in equal proportions then a vulnerability in one would clearly not have the impact of a vulnerability that affects everything. (Do I seriously have to spell that out? Is it not obvious?) You are arguing from the position that it would be impossible to approach OpenSSL quality if resources were split across multiple implementations, but this event has demonstrated that the 1000 eyes theory is nonsense. That bug wasn't there a short time before being found, it was there for years.
It seems obvious that this is going to spawn a Rust/Ocaml/similar reimplementation of SSL to me. The reason it's damning is this is only going to happen because the wider community now deems it necessary, when really it should have been a measure that the eternally loud security contingent took on proactively.
"If we had multiple equally used SSL implementations of equal quality and used in equal proportions"
Then either 1) each would be of substantially lower quality than if the same development effort had been focused on one, or 2) you've pulled a bunch of smart developers off of other projects.
Biological metaphors are interesting, but software faces different constraints.
The big truism of software development is that motivated small teams can do proportionately much more than the same people would if they're all thrown in one big group on one project. The whole mythical man month at work.
It's not even true that open source SSL is a monoculture. There are two critically important open source TLS implementations, not one (NSS and OpenSSL), and that's not counting SecureTransport (Apple's open-source implementation).
I don't think there's a single part of your argument that really survives scrutiny. Your central point is false, as are its premises. To the extent that a large portion of the Internet uses one TLS implementation, that's often been as helpful as harmful. And the "monoculture" you're decrying is counterfeit: you seem to think OpenSSL is the only credible option, but Chromium and Firefox disagree with you.
Aren't two of the three implementations you're mentioning mainly used in clients though? Most Linux boxes are not used as clients, and so there is a monoculture of Linux server security.
You, rightly, mentioned NSS elsewhere, but do people actually use this on servers in any great number? I guess you could argue that Apache and Nginx shipping OpenSSL as the default option for https is the problem, in which case shouldn't we change that, or is there something else about OpenSSL that prevents people from using NSS?
NSS implements both the client and server side of TLS. And OpenSSL and NSS aren't the only options; if X.509 bugs are more your style, you could try PolarSSL or MatrixSSL:
Fill in the blank: 50% of the things being compromised is ______% as bad as all the things being compromised.
Sometimes a partial compromise is easy to deal with, and the number in the blank is way less than 50. Lots of diverse things is good.
Sometimes half the units being compromised is almost as bad as all the units being compromised. Lots of diverse things is a bad thing in this environment.
It's absolutely true. To the degree that your objection holds (which isn't negligible), it places some limits on the return possible from 1. 2 still fully applies. I'm also not sure what the limits in 1 are, when what we need is more careful code and better analysed code, rather than more code. "Find problems" shouldn't involve tremendous amounts of communication overhead.
The very reason HSM vendors will be shouting about this for years as well, as anyone using those will at least have ensured their private key hasn't gone AWOL.
And that is the same recommendation you'd have made as a week ago? (In fairness, I can believe it might be).
I am honestly struggling to see how you don't think having all Linux servers running incredibly similar crypto stacks is a bad thing. For sure HSMs and Windows boxes add to the diversity of the world, but Linux boxes form such a massive proportion of servers connected to the net that any common vulnerability there is a major problem.
Just assuming you've found all vulnerabilities is not the way to go, so mitigating the effect of a vulnerability happening seems like a reasonable thing to do. After all, this is a good reason for things like process separation.
The most consistent complaint about OpenSSL is that it is developed amateurishly (I think it's more complicated than that, but "amateurish" is a fair summary of the critique). Your response seems to be, "double down on amateurish!"
PS: The only reason you know about heartbleed is that one of the self-proclaimed "experts" found it for you. Neel Mehta is an insider's insider.