How the Heartbleed Vulnerability Shaped OpenSSL as We Know It

Few are the bugs that truly make it into mainstream notoriety. Whether having to do with its unabashedly dramatic name and logo or with little relation, the Heartbleed vulnerability is one flaw that has become a household name.

Made public in April 2014, the Heartbleed vulnerability ( formally designated CVE-2014-0160 ) was a simple coding mistake that left a vulnerability in the heartbeat extension (RFC 6520) of OpenSSL; an open source library providing cryptographic functionality to secure web servers. With over 66% of web servers using OpenSSL at the time of disclosure, two-thirds of the world’s web traffic was compromised by this vulnerability. OpenSSL released a software patch within a week of the bug’s disclosure, sending hundreds of thousands of affected developers and site admins on a patching frenzy.

But the effect of the Heartbleed vulnerability on the developer community did not end with the prompt call to remediate. Like other big-name open source security vulnerabilities that came before it, Heartbleed seemed to generate a climate of trepidation about the use of open source. Much was said about OpenSSL being maintained by a mere two developers (both named Steve) with little funding and practically no resources. Conversations ensued about what would have happened had the vulnerability been in a bigger project. Would it have been discovered earlier? How would it have been handled? Daggers were thrown by the bucket full at the two year gap between OpenSSL’s release of the buggy version and the discovery of Heartbleed therein. And once again a developer-wide conversation began about the reliability of open source and how safe it was to use.

By and large, the response to the incident was unanimous in pointing to the imbalance between the widespread use of OpenSSL and (Read more...)