Netcraft’s site reports now make it easy to see which websites have or have not revoked their SSL certificates in response to the Heartbleed bug.

Around 17% of all trusted SSL web servers were vulnerable to the Heartbleed bug when it was publicly disclosed earlier this month. The bug made it possible to steal a server’s private keys, thus allowing unauthorised parties to impersonate an affected website using its own SSL certificate. Consequently, around a quarter of the 500,000+ potentially-compromised certificates have already been reissued to date, but despite the importance of doing so, relatively few of these have also been revoked.

Some website administrators quickly responded to the Heartbleed bug by upgrading OpenSSL and issuing new SSL certificates, but issuing new certificates alone is not enough. Despite the difficulties involved in online revocation checking during a man-in-the-middle attack, the previous, possibly-compromised certificates must be revoked. Revocation checking can still be effective in some cases, especially when the revocation is included in Google’s CRLSets.

For example, Yahoo had several high-profile websites which were vulnerable to the Heartbleed bug, and if the SSL certificates’ private keys were compromised, they still are. Although the underlying OpenSSL vulnerability was quickly fixed on Yahoo’s servers, it was not quick enough to prevent the vulnerability being exploited to reveal some of the email addresses and passwords used by Yahoo users. Yahoo has since reissued the affected certificates, and with the possibility of a key compromise, it would also have been sensible for Yahoo to revoke the old ones — but they have yet to do so.

Netcraft’s site report for https://login.yahoo.com shows that the site offered the Heartbeat TLS extension prior to the Heartbleed disclosure, but is now using a new certificate. However, the new Heartbleed revocation section shows that the certificate previously used on login.yahoo.com has not yet been revoked. This means that anyone who uses Yahoo Mail, Yahoo Messenger, Flickr – and anything else which uses Yahoo’s single sign-on mechanism – could still be vulnerable to man-in-the-middle attacks until it is revoked, or if not revoked, until February 2015.

Unfortunately, even when a certificate has been revoked, there is no guarantee that it cannot still be used to carry out man-in-the-middle attacks. If the attacker is also able to hijack OCSP requests, then he can exploit a browser’s “soft-fail” approach to revocation checking, where a failed request will cause the browser to assume that the certificate is still good. CRLs (and Chrome’s CRLSets) potentially offer slightly better protection under these circumstances, as the revocation lists may have already been downloaded while the browser was connected to a trusted network.

Yahoo is not alone in failing to revoke all of the certificates it reissued in response to the Heartbleed bug. At the time of writing, other companies in the same boat include Twitter, LinkedIn, Facebook, Apple, FedEx, PayPal and American Express, as well as the Schneier on Security blog. Many of these websites use Akamai’s content distribution network, which was previously vulnerable to Heartbleed.

But why haven’t all sites revoked their potentially compromised certificates? Some believe that online revocation checking is useless, some may not want to incur the cost of revoking a certificate, and many others may simply not realise (or believe) it necessary. Nevertheless, anybody who reissued a certificate in response to the Heartbleed bug presumably accepted there being some risk of the previous certificate being misused, in which case there is little justification for not revoking the old certificate. Administrators may want to delay revoking certificates to ensure that the new certificate has been fully deployed, but arguably, certificate authorities should not allow the delay between reissuance and revocation to stretch to several weeks.