Tudor Dumitraș

Assistant Professor
ECE Department
University of Maryland, College Park

Certificate Reissues and Revocations in the Wake of Heartbleed

| Comments

The ability to revoke SSL certificates is key to protecting Web users from rogue sites trying to intercept secure communications over HTTPS. The SSL certificate of a Web site — say, mail.google.com — includes the site’s public key, signed by a Certificate Authority (CA) that vouches for the site’s true identity. An attacker with access to the corresponding private key can set up a site claiming to be mail.google.com; when users vist this site, their browsers will successfully validate the SSL certificate and will display the lock icon that confirms the establishment of a secure channel. Meanwhile, the attacker will be able to conduct a phishing scam (by stealing private information sent to trusted Web sites, e.g. passwords) or a man-in-the-middle attack (by forwarding the requests to the real site, while eavesdropping on the communication channel). This is a very realistic threat: for example, in 2011 an Iranian hacker compromised the Comodo and DigiNotar CAs and managed to issue valid certificates for mail.google.com, login.live.com, login.skype.com, and other popular sites. The recent Heartbleed vulnerability posed a similar threat.

Heartbleed was a bug in the OpenSSL cryptographic library, used by many popular Web servers, that allowed attackers to retrieve up to 64 KB of private data from the server’s memory. Experiments have shown that these data dumps sometimes include the server’s private SSL key. To prevent these memory dumping attacks, you have to update OpenSSL to a patched version. However, there is another threat: the site’s certificate may have been compromised by an attacker who was able to retrieve (undetectably) the private key by exploiting Heartbleed. To prevent phishing and man-in-the-middle attacks, you have to revoke all the certificates that were used in conjunction with vulnerable OpenSSL versions and to issue new certificates.

In our IMC’14 paper, we used a set of certificates advertised by the Alexa Top 1 Million domains over a period of six months, and the corresponding Certificate Revocation Lists (CRLs), to measure how quickly the certificates that may have been compromised by Heartbleed were revoked and reissued [IMC 2014]. Once the vulnerability was disclosed, it was important to replace the SSL certificates quickly, as another IMC’14 paper showed that attacks seeking to exploit Heartbleed started 21.5 hours after the public disclosure. However, we found that, even though most vulnerable servers in the Alexa Top 1 Million were patched quickly, over 73% of vulnerable certificates had yet to be reissued three weeks after Heartbleed was disclosed. More strikingly, and contrary to common assumptions, we found that revocations occur at an even lower rate: over 87% of vulnerable certificates had yet to be revoked three weeks after disclosure. Some sites issued new certificates while re-using the old private key. We observe a similar gap between the rate of reissues and revocations for Extended Validation (EV) certificates, which are subject to a more stringent identity verification process. Web sites that reissued certificates without revoking them include mlogin.yahoo.com, entry7.credit-suisse.ch and lfts.senate.gov. This gap is striking because reissuing a compromised certificate without revoking it or without generating a new keypair does not stop phishing and man-in-the-middle attacks, as rogue Web sites with access to the stolen keys can still masquerade as legitimate sites.

We have a longer discussion about the causes and implications of this problem in our full paper [IMC 2014]. There are some rational explanations, such as the fact that certificate revocations are difficult (some CRLs grew by two orders of magnitude after Heartbleed and became unresponsive because of this spike in traffic) and insufficient for preventing attacks (an attacker may be able to prevent the client from accessing the CRL, in which case many web browsers still accept the certificate as valid). However, it also seems that many site administrators did not understand the security implications of reissuing SSL certificates without revoking the old ones. Ultimately, Heartbleed showed us that the security of the HTTPS ecosystem relies on a process that requires manual intervention from certificate owners and cooperation from clients using these certificates and that is ill prepared for handling mass revocations.

Paper: [IMC 2014]

Data set and supplemental information: http://www.securepki.org/


  1. [IMC 2014] L. Zhang, D. Choffnes, T. Dumitraș, D. Levin, A. Mislove, A. Schulman, and C. Wilson, “Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed,” in ACM Internet Measurement Conference (IMC), Vancouver, Canada, 2014.