The Heartbleed recovery starts with you and me

As we pick up the pieces after the OpenSSL meltdown, let's all reflect on why a globally important open source project had only one full-time developer

Yes, we get it. OpenSSL really screwed up -- for a long time. And nobody who knew about it said anything. Meanwhile, millions of "secured" sites were helpfully vomiting up 64KB chunks of process memory just for the asking.

Yeah, it sucks.

[ Also on InfoWorld: The rise and fall of Heartbleed hysteria | How to rethink your security strategy for today's world. Bonus: Available in PDF and e-book versions. | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

But as I wrote last week, if you keep your production systems a release or two behind current, you were probably fine. If you were running OpenSSL 1.0.1 and had a large vulnerable footprint, you hopefully had orchestration tools in place and were able to patch those systems quickly. Of course, that doesn't help with the rekeying and cert regeneration that everyone is probably still sorting through, but at least you could stop the bleeding.

Now comes the backdraft. After everyone was able to put out their fires and get a handle on Heartbleed, we get the inevitable blame game, holier-than-thou proclamations, threats, and forking that this kind of event engenders. For instance, OpenBSD is overhauling OpenSSL. It's likely that this will turn into an OpenBSD-centric fork of OpenSSL rather than being accepted back into the OpenSSL base -- but who knows at this point?

Then there was Akamai's claim to be invulnerable because it used a custom memory allocator it had written into OpenSSL, but not contributed back to the project. Of course, that software was later proven to be vulnerable and Akamai's method still unsafe.

There have been lots of accusations and lots of people discussing the OpenSSL codebase as if it was a festering cesspool of awful code. There have been loud but baseless plans to reinvent open source SSL altogether. I alluded to the core of the matter at the end of my column last week: OpenSSL has been neglected for a long time. It has been taken for granted by developers and companies for more than a decade, and in the meantime, it has been implemented in two-thirds of all Web servers.

Let's put that into perspective. Netcraft says it received responses from 861,379,152 websites -- that's a fuzzy number, but good enough. That means roughly 573,678,515 websites are running OpenSSL code. In fact, those websites rely solely on OpenSSL for any and all encryption protection. That's a massive number of users for any software, be it commercial product or open source project -- yet there's only one full-time developer of OpenSSL.

OpenSSL has 11 team members scattered across several countries, most of whom are volunteers -- the sort of team that we ordinarily see on an open source project with a far smaller footprint. Clearly, OpenSSL has been flying well under the radar, a nearly invisible but massively important cog in the economy of nearly every nation on Earth -- the foundation of secure communications across the globe.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform