German OpenSSL developer Robin Seggelmann spoke openly and was quoted by several newspapers about his commit which ultimately introduced the bug responsible for Heartbleed, essentially accepting responsibility and offering a mea culpa of sorts – no doubt in an attempt to quell the growing concern that this bug was perhaps planted by the NSA.
At the risk of sounding like a conspiracy theorist (and I will remind readers that prior to the Snowden disclosures most would have accused those speaking of the reach of the NSA’s intercept program as being a nut despite evidence of the existence of such a program being widely accepted as early as the Room 512A documents) I will admit that when news of Heartbleed broke I was immediately suspicious. The simplicity of the error and the ease of which it could be dismissed as an innocent mistake are the alleged hallmarks of the work of the agency and this essentially mirrors the style of the 2003 attempt to backdoor the Linux kernel, the only difference being the latter was caught – minimum modification yet maximum damage to the integrity of the software.
When one considers the number of websites using OpenSSL (not to mention embedded devices and appliances – which will likely remain affected while their vendors slowly push out patches) and the duration that a large portion of the internet was vulnerable it is unsurprising that some are asking questions. I would suspect that even if the NSA were not directly responsible that knowledge of the 0day would have been a very valuable thing and given their resources independent discovery is a possibility.
I wish to add a disclaimer that I am not seriously suggesting that Heartbleed was deliberate and the aforementioned developer responsible, but it is interesting to consider that it is likely now an unfortunate reality that in a post Snowden world any future vulnerabilities discovered in any software will be scrutinized and suspicions cast toward shadowy government spooks. I don’t necessarily think this is a bad thing, especially if it results in more eyes auditing the code that so many came to blindly rely on.
Mike the Crypto Goat 
I consider intense scrutiny of developers responsible for such fail perfectly appropriate. There comes a time when we need to raise the bar for contributing to open source projects, especially for security sensitive ones. If every commit one makes to a critical codeset puts one at risk of second guessing, loss of reputation and shunning, one will exercise more care. At worst this may slow development of security critical code, but I would not consider that a problem. At best we have fewer issues like this. Poorly thought out “standards” like the heartbeat extension could have used more skeptical vetting and less immediate implementation.
At the moment, even without proof of wrongdoing, I strongly suspect Rescorla and anything he has had his hands in. Even if blameless, his commits evidence sloppiness at best, with compromise or intentional subversion well within the bounds of reason.
I suspect heartbleed will result in numerous young developers creating their own versions of OpenSSL in their languages of choice. Within a year we will probably have dozens of possibilities. The many eyes that make bugs shallow will fragment. Nobody but intelligence agencies will have the resources to evaluate all the SSL/TLS stacks, leaving them with the knowledge to exploit next generation SSL/TLS implementations while young idealist sysadmins march forward on putting them into production to get rid of that icky, dirty, nineteen-seventies (FFS!) C code that doesn’t bounds check.
And we will all end up worse off.
Agreed. Look at some of the sockets code in BSD that hasn’t significantly changed in years – why? Because the damn code works.
Holding commits to security critical code to a higher level of oversight is absolutely critical.
As you’ve mentioned we risk shooting ourselves in the proverbial if the open source community doesn’t “grow up” and learn of the collective danger to the entire OSS ecosystem such incidents pose.
I don’t think OpenSSL dying is necessarily a bad thing given the longstanding issues with its code quality. We have plenty of other TLS libraries that are better candidates for a long term viable candidate IMHO.
Amen!
I’m more than happy to have OpenSSL fade into “no new project ever uses it” status, though with embedded stuff out there we may never actually get rid of it for good.
We urge two factor authentication everywhere but don’t even bother to implement two-phase commit on our security code bases?
Fine, be agile (or whatever the kids call it this month) with the Android games that data mine mobile devices. For the love of all that’s holy let’s NOT be agile with security critical libraries used all over the network!