The SSL/TLS protocol suite has become the de facto secure protocol for communications on the Web, protecting billions of communications sessions between browsers and servers on a daily basis. We use it every time we access our social media feeds, or whenever an app running on our mobile device wants to contact its home server. It has become an almost invisible part of the Web’s security infrastructure, supported by an eclectic mix of technologies including public key cryptography, certificates, and the Web PKI.
So when a serious security vulnerability is discovered in the SSL/TLS protocol itself, or in one of the main implementations like OpenSSL, one would naturally expect a rapid response—system administrators would roll into action, patching their software as quickly as possible, and taking any other remedial actions that might be necessary.
The following paper by Zhang et al. paints a very different picture in the context of the most famous SSL/TLS vulnerability of all, Heartbleed. The Heartbleed vulnerability resides in the OpenSSL implementation of the Heartbeat protocol. The Heartbeat protocol is an extension of SSL/TLS for checking the "liveness" of a connection. The Heartbleed bug lay in OpenSSL’s failure to correctly perform bounds checking when processing Heartbeat messages. An attacker, situated anywhere on the planet, could induce a server to return large amount of data to the attacker from arbitrary (but uncontrolled) portions of its stack. This memory leak would allow the attacker to learn a vulnerable server’s private key, with disastrous security consequences.
Heartbleed became public in early April 2014. The Internet community rapidly developed free Heartbleed scanning services, and published statistics on vulnerable servers. Some websites were actually attacked, though all hosts in the Alexa top 500 were patched within 48 hours. As well as immediately patching OpenSSL to remove the vulnerability, security experts recommended that system administrators should revoke their public key certificates, generate new key pairs, and request their Certification Authorities (CAs) to issue new certificates. Private keys, among the security "crown jewels" for SSL/TLS, had potentially been compromised.
The following paper examines to what extent revocation and reissuance of certificates happened post-Heart-bleed. The short and surprising answer: not so much. Zhang et al. cleverly use the Heartbleed incident as an opportunity to perform a natural experiment, tracking the rate at which large websites from the Alexa top 1M chose to revoke and reissue certificates. They carefully assess the extent to which those sites would have been vulnerable to Heartbleed, and then use the open nature of the Web to collect information about when those sites’ certificates were actually changed, and whether the previous certificates were properly revoked. To a security-conscious reader, the final statistics make depressing reading. For example, of roughly 107,712 vulnerable websites (that is, websites for which the private key could have been exposed), only 26.7% had reissued certificates by the end of April 2014, while 60% of those sites did not properly revoke their old certificates (meaning that, had the corresponding private keys been exposed, the sites would still be vulnerable).
The authors discuss some of the reasons why such low rates of revocation and reissuance were seen. They also report anecdotal evidence gleaned from surveying system administrators. A key reason is the processes are manual rather than being automated. One may also advance the argument that customers pay CAs for certificates, and security budgets are always under pressure. One possible perception is that the window of exposure was small, because most vulnerable systems were patched quickly. This belies the fact that the vulnerability was present in the OpenSSL code for more than two years, and could have been exploited during that time. A third possible reason is ignorance on the part of sysadmins: while patching is part of the everyday sysadmin culture, dealing with certificates and keys is not. The paper points out a more systematic study is needed in order to understand certificate management and how it is tackled by sysadmins.
More broadly, the Heartbleed incident has had a lasting and net-positive impact on the security of the Web. The bug led to a much closer inspection of the OpenSSL code base, leading to other problems being subsequently discovered. It also led to a wider debate about the wisdom of having a security monoculture, about the quality of the OpenSSL code, and about the way in which the OpenSSL project was being run. And it triggered a debate about the responsibilities of large companies who make free use of open source software like OpenSSL without contributing materially to its development.
Heartbleed resulted in major industry players forming the Core Infrastructure Initiative, a project intended to fund critical elements of the global information infrastructure. OpenSSL has in turn significantly revised its operations, expanded the development team, and heavily refactored the codebase.
In parallel, Google initiated its own fork of OpenSSL called BoringSSL. The naming is considered, with "boring" being intended to convey an impression of "no nasty surprises." In October 2015, Google announced it had switched over to BoringSSL across its entire codebase (comprising several billion lines of code).
The "Let’s Encrypt" initiative has started to address the problem of helping sysadmins to better manage certificates. Let’s Encrypt is a free CA, which simplifies the process of obtaining certificates and switching on SSL/TLS for websites. In mid-2017, its 100-millionth certificate was issued, and Mozilla’s telemetry indicated more than half of all HTTP connections were protected.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment