Unless you’ve been living in a cave for the past 3 months you have heard of the Heartbleed bug in OpenSSL. Since the disclosure of Heartbleed there have been many positive actions taken by the security community. This post will highlight those actions in light of Heartbleed, and how they will lead to a more secure Internet overall.
One of the most publicized actions was the forking of OpenSSL by the OpenBSD community. According to OpenBSD’s Bob Beck the real impetus for the fork was the discovery of OpenSSL’s proprietary memory management functions – a system which the OpenBSD team euphamistically labelled, “exploit mitigation technique countermeasures.” However, to observers it’s hard to imagine that Heartbleed wasn’t an important impetus. Regardless of reason, the OpenBSD team has been hard at work on their own fork of OpenSSL for approximately six weeks now. It’s called LibreSSL, and their aims are to maintain backward compatibility with OpenSSL’s API for POSIX-compliant operating systems. Most of their changes have been to remove support for older platforms and make the code more accessible. Right now they’re focusing on OpenBSD compatibility, but their long term goal is to make LibreSSL run on all *NIXes. For a great explanation of LibreSSL, and where it’s headed, check out Bob Beck’s recent presentation at BSDCan.
OpenSSL also received an injection of support from the Linux Foundation. In a wonderful effort to ensure security in OpenSSL, OpenSSH and NTP, the Linux Foundation has agreed to fund a security audit and two full-time developers for OpenSSL. This is great news for all three projects, but especially for OpenSSL. This news came right before OpenSSL issued a security advisory for seven vulnerabilities on June 5th.
In addition to OpenSSL and LibreSSL, we shouldn’t forget GnuTLS. The SSL/TLS library licensed under the LGPLv2. GnuTLS has also seen a recent flurry of activity with three security vulnerabilities found in 2014.
With all the activity in this space, including all the found vulnerabilities, should we be worried? With three competing libraries for SSL/TLS does that mean we’re less secure? The answer to both is a resounding ‘No’! When vulnerabilities are found it means people are looking at the code. Remember Linus Torvald’s Law, “Given enough eyeballs, all bugs are shallow.” If we aren’t finding vulnerabilities, it probably just means no one is looking at the code.
Also, diversity is good for security. In their 2011 study, “OS Diversity for Intrusion Tolerance: Myth or Reality?”, researchers Miguel Garcia, Alysson Bessani, Ilir Gashi, Nuno Neves and Rafael Obelheiro examined how diversity affected intrusion tolerance in networked operating systems. Using vulnerability data from the NIST National Vulnerability Database from 1994 to 2010, they looked at how many exploits affected more than one operating system across 11 operating systems. Their results should be obvious to security professionals, but bear repeating for their empirical certainty. Diversity of code base decreases the probability of common vulnerabilities. In other words, having distinct code bases makes us more secure, in much the same way having distinct DNA increases a species’ disease resistance.
In their own words, “We analyzed more than 15 years of vulnerability reports from the NIST Vulnerability Database totaling 2120 vulnerabilities of eleven operating system distributions. The results suggests substantial security gains by using diverse operating systems for intrusion tolerance.” They also discuss how their conclusions regarding operating systems can be generalized to other interchangeable software components, such as SSL/TLS libraries.
To sum up, disclosing vulnerabilities and implementation diversity are good for security, and good for the Internet. To find out more about TLS for Applications visit our resource page on TLS for Apps. Also check out the IETF’s Using TLS in Applications(UTA) working group to find out how you can get involved in this important conversation.