Only 30,000 of the 500,000+ SSL certificates affected by the Heartbleed bug have been reissued up until today, and even fewer certificates have been revoked.
There has been a noticeable rise in certificate re-issuance since 7 April 2014
Some of the first sites to deploy newly issued certificates in response to the OpenSSL vulnerability included Yahoo, Adobe, CloudFlare, DuckDuckGo, GitHub, Reddit , Launchpad, PayPal, Netflix and Amazon’s CloudFront content delivery network.
Such is the haste to fix the fallout of the Heartbleed bug, some certificate authorities and website administrators have been making careless mistakes. PayPal’s Hosted Message Applications, such as the one at
https://view.paypal-communication.com, are now using Extended Validation certificates issued by VeriSign on 10 April 2014. The
CAB Forum requires certificate authorities to adhere to a
stringent set of guidelines [pdf] when issuing EV certificates, and it is the CA’s responsibility to verify the accuracy of the information in the certificate. In particular, they must verify that the legal name of the subject in an EV certificate matches the name which appears on official government records.
However, this verification does not appear to have been performed correctly in the case of these certificates, as they have been erroneously issued to an organisation named "PayPal, Inc.\0a" instead of "PayPal, Inc."
Extended Validation certificates cause browsers to display a green dialog, indicating the additional — and supposedly more accurate — identify verification criteria.
If you don’t revoke your certificate, you may still be vulnerable to impersonation
If your private key has been stolen, just reissuing the certificate is not enough to mitigate the risks posed by the Heartbleed bug. Websites which were affected by the bug could still be vulnerable to impersonation attacks in the future if they fail to revoke their certificates, even if they have upgraded to the latest version of OpenSSL and replaced their SSL certificates.
If a remote attacker successfully retrieved private keys from a server while it was still vulnerable to the Heartbleed bug, then he would be able to impersonate the server by creating his own valid SSL certificate. The crucial issue is that an attacker can still do this after the affected website has upgraded to the latest version of OpenSSL, and it does not matter whether the real website has since deployed a new SSL certificate with different keys: Unless the previous certificate is revoked, the site will still be vulnerable to man-in-the-middle attacks.
Certificate revocations have gone up, but most of the vulnerable certificates are yet to be revoked.
Despite the importance of revoking certificates which could have been stolen using the Heartbleed bug, many website administrators and certificate authorities have yet to do this. Activity on certificate revocation lists peaked at a rate of 2,600 revocations per hour on the day the Heartbleed bug was announced (Monday April 7, 2014). On a typical Monday, we would expect to see a total of around 10,000-14,000 SSL certificates being revoked over the course of the day. On the Monday that the Heartbleed bug was announced to the public, this figure jumped to more than 18,000, suggesting that at least 4,000 of these revocations were in direct response to the Heartbleed bug. On the next day (Tuesday), 16,000 certificates were revoked, followed by 17,000 on Wednesday. Note that fewer revocations usually take place over weekends.
Certificate authorities must revoke certificates within 24 hours if there is evidence of a key compromise. A private key is said to be compromised if its value has been disclosed, or if there exists a practical technique by which an unauthorised person may discover its value. Arguably, all certificates on sites vulnerable to the Heartbleed bug should be revoked by now, as such a technique was successfully carried out by the researchers behind heartbleed.com.
Even if you revoke your certificate, you may still be vulnerable to impersonation
However, even if all of the affected certificates were to be revoked, contemporary web browser software handles certificate revocation poorly. The most frequent users of a site — often its administrators — can continue using a revoked certificate for weeks or months without the browser notifying them that anything is amiss. In this situation, an attacker can perform a man-in-the-middle (MITM) attack by presenting the certificate to unsuspecting users whose browsers will behave as if they were connecting to the legitimate site. For example, some browsers only perform OCSP revocation checks for Extended Validation certificates, while others ignore certificate revocation lists completely.
You are encouraged to read our previous article on certificate revocation.
