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/
References
[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.
PDF