Human error is behind the latest threat to website security but giant corporations need to take their share of the blame
The Heartbleed coding error may have been around for three years, affecting two-thirds of computer servers. Photograph: Pawel Kopczynski/Reuters
Were you a thriller writer seeking a name for an apocalyptic software security flaw that threatened the future of civilization as we know it, then "Heartbleed" would be hard to beat. Last week saw the discovery of such a flaw, and Heartbleed was the name assigned to it.
Most security flaws are of interest only to specialists, but this one was different. Why? Because it's been around for something like three years, during which time it could have exposed the passwords and credit card numbers that countless millions of people had provided to online stores and other services. Heartbleed would enable attackers to eavesdrop on online communications, steal data directly from services and users, and impersonate both services and users. It could have affected up to two-thirds of the world's internet servers. And unlike some earlier such problems, the solution isn't as simple as immediately changing one's password. It was, said Bruce Schneier, a security expert not much given to hyperbole, a "catastrophic" flaw. "On the scale of one to 10," he wrote, "this is an 11."
Heartbleed is a flaw in the computer code that encrypts your personal data while it's in transit from your computer to an online service. When you buy something from Amazon, say, or proceed to the checkout on any reputable site, then the URL you're dealing with will change from one prefixed by "http" to one prefixed by "https". This indicates that the Secure Sockets Layer (SSL) protocol has been invoked and that your personal data will now be transmitted only in encrypted form.
SSL is an essential component of the global e-commerce system, and the most common implementation of it is an open-source version called OpenSSL. Any flaw in it could indeed be catastrophic – which is why there was such a furore a while back when it was revealed that the National Security Agency had apparently been working actively to weaken the cryptographic protection that SSL offered. Not surprisingly, therefore, the default assumption when the Heartbleed story first surfaced was that the NSA must be behind it. But this comforting conjecture was rapidly discounted when it was realized that the flaw was most probably the result of a relatively mundane programming error.
It turns out that within OpenSSL there is something called the "heartbeat" protocol. This is needed to ensure that communications between user and site are kept alive even when the line goes quiet. What seems to have happened is that when one of the programmers who works on OpenSSL was doing a software update in 2011, he made a coding error which then – unusually for open-source software – went undetected for several years.
The implications of this are both intriguing and troubling. It's possible that the flaw – and the opportunities it provided for undermining the protections offered by SSL – was indeed undetected by anyone and that therefore the world of online commerce was safe even though the door to the safe was swinging open in the breeze. But most security people are unwilling to make that bet. Instead they are assuming that some people knew about Heartbleed and have been either quietly exploiting the vulnerability or using it to hoover up personal data for later nefarious uses.
An equally troubling implication is that huge online companies, instead of developing their own SSL code, simply lifted the OpenSSL code and just bundled it into their web-service software. They are perfectly entitled to do this, provided that they adhere to the terms of open-source licensing. But in behaving as they did they have in effect been free-riding on the public domain.
Most open-source software – and Open SSL is no exception – is produced voluntarily by people who are not paid for creating it. They do it for love, professional pride or as a way of demonstrating technical virtuosity. And mostly they do it in their spare time. Responsible corporate use of open-source software should therefore involve some measure of reciprocity: a corporation that benefits hugely from such software ought to put something back, either in the form of financial support for a particular open-source project, or – better still – by encouraging its own software people to contribute to the project.
If the giant internet companies had taken the latter approach to OpenSSL, then they might have spotted the Heartbleed vulnerability earlier. In which case we wouldn't be in the mess that we are in now. Sometimes the ethical thing to do turns out also to be the prudent thing to do.