More than 80,000 SSL certificates were revoked in the week following the publication of the Heartbleed bug, but the certificate revocation mechanisms used by major browsers could still leave Internet users vulnerable to impersonation attacks. Little has changed since Netcraft last reported on certificate revocation behaviour.
Why is revocation necessary?
The Heartbleed bug
made it possible for remote attackers to steal private keys from vulnerable
servers. Most web server access logs are unlikely to show any evidence of such a
compromise, and so certificates used on previously-vulnerable web servers should be replaced without delay.
However, even if the certificate is replaced, the secure site could still be vulnerable. If the pre-Heartbleed certificate had been compromised, it will remain usable by an attacker until its natural expiry date, which could be years away. A correctly positioned attacker, with knowledge of the old certificate's private key and the ability intercept a victim's internet traffic, can use the old certificate to impersonate the target site.
Certificate authorities can curtail the lifetime of the compromised certificate by revoking the certificate. In principle, a revoked certificate should not be trusted by browsers, which would protect users from misuse of the certificate. The realities of revocation behaviour in browsers, however, could leave some internet users vulnerable to attack with compromised certificates.
The Heartbleed bug is currently the largest cause of certificate revocations,
but other reasons for revoking certificates can include the use of
weak signature algorithms, fraudulent
issuance, or otherwise breaching the requirements laid out by
the CA/Browser Forum.
How does revocation checking work?
There are two main technologies for browsers to check the revocation status
of a particular certificate: the Online Certificate Status Protocol (OCSP) and
Certificate Revocation Lists (CRLs). OCSP provides real-time revocation
information about an individual certificate from an issuing certificate
authority, whereas CRLs provide a list of revoked certificates which is
typically retrieved by clients less frequently.
Of the major browsers, only Internet Explorer and Opera behave
correctly in a wide variety of revocation scenarios, including where end-entity
and intermediate certificates had been revoked only via a CRL or only via OCSP. The remaining browsers — Google Chrome, Safari, and Firefox — all have less consistent behaviour when checking the revocation status of SSL certificates.
Firefox blocks access to certificates which have been revoked via OCSP.
OCSP, the more recent standard, is effectively the revocation method of choice on the internet: providing the URL to a CRL in individual certificates is optional in the Baseline Requirements, and only Opera and Internet Explorer consistently check them when OCSP is not available. The latest version of Firefox removed the last vestiges of CRL checking: previously CRLs were checked only for EV certificates when OCSP failed.
Although CRLs have some disadvantages — their size for one — they do offer some key advantages over OCSP: CRLs can be downloaded ahead of time on a trusted network and, unlike OCSP, CRLs do not reveal which sites you are visiting to the certificate authority.
Google's decision to disable OCSP checking by default was also partly due to these privacy concerns.
OCSP
stapling is an alternative approach to distributing OCSP responses. By including a recent OCSP response in its own
TLS/SSL handshake, a website can remove the need for each visitor to make a separate connection to the certificate authority. As well as improving performance, stapled responses remove the privacy concerns surrounding standard OCSP leaking user IPs to certificate authorities. However, only 24% of all SSL certificates found in the most recent Netcraft SSL survey were used on websites that stapled an OCSP response.
Google has shunned the traditional methods of revocation: whilst Chrome does check the status of EV certificates, revocation checking is not enabled by
default for any other type of certificate. Instead, Chrome uses its
own updating mechanism to maintain an aggregated list of revoked certificates gathered by crawling CRLs. This is a subset of all revocations and is intended to cover only the most important.
Is revocation checking useful for certificates potentially compromised by Heartbleed?
As explained by Adam Langley, online revocation checking can easily be blocked if the compromised certificate is being used in a man-in-the-middle attack. An attacker able to intercept traffic to the targeted website will likely also be able to block OCSP requests. If the victim is using a browser which does not hard-fail (which is the default setting of all major browsers) when an OCSP response isn't received, the attacker will be able to use a revoked certificate as normal.
However, the same logic does not apply to CRLs: if the CRL was downloaded earlier when on a trusted network, a revoked certificate used in a man-in-the-middle attack will not be trusted. This requires the certificate to have been revoked before the CRL was downloaded; however, many CRLs can be cached for a significant length of time (up to 10 days in the Baseline Requirements). Although, if a new CRL is needed, its download can be blocked just as effectively as OCSP's can be. When CRLs are used, an attacker cannot rely on the certificate passing validation: a subset of users, those with cached CRLs, will be prevented from continuing on the attacker's site. The same logic also applies to Google's CRLSets, including the ability to block updates.
As such, despite the difficulties of revocation checking in the MITM scenario, it is still critical for site owners to revoke certificates. If the certificate is revoked, an attackers job is made that much more difficult: he must chose sites with certificates issued without a CRL distribution point (which is permissible under the Baseline Requirements) or that are not covered by Google's CRLSets, and his victims must be using a browser that checks neither. Certificates that are not revoked are unlikely to ever be included in more effective revocation methods such as CRLSets.
Should I enable revocation checking in Chrome?
Whilst OCSP is easily blocked in man-in-the-middle attacks, if revocation checking is enabled, Chrome (on both Windows and Linux) will check CRLs for certificates that do not support OCSP. It is likely that you will have cached CRLs for websites you have visited recently — if you move onto an untrusted network, you will be protected by the CRLs that were downloaded earlier. Over 4% of currently valid certificates are only revocable by CRL, including login.skype.com. Unfortunately, for the majority of sites where OCSP is available CRLs will not be downloaded, any OCSP requests made can be blocked, and the attacker can continue as if the certificate is not revoked.
Perfect OCSP checks: A chicken and egg problem
By default, all browsers take the "soft-fail" approach to OCSP checks. A revoked certificate
will be regarded as valid if the OCSP request fails. While this sounds
like unsafe behaviour, browser vendors are reluctant to force a hard-fail
approach because of the problems it can cause. For example, paid-for internet connections,
such as WiFi hotspots or hotel room connections, that use captive portals are one of the major
chicken-and-egg scenarios.
Before a user can access the internet, he must visit a secure payment page, but this would fail because the OCSP responder used by the site's certificate cannot be reached until after he has paid. There are methods to resolve this problem, including OCSP stapling and less restrictive blocking; however, such solutions are unlikely to adopted quickly.
Firefox can be forced to use a hard-fail approach to OCSP checking, but this
setting is not enabled by default.
It is critical that OCSP responders have
100% uptime, as any outage whatsoever could provide a window of opportunity to
misuse compromised revoked certificates. Netcraft publishes a list of OCSP responder sites
ordered by failures over the past day. Partly due to the reliability concerns, the Mozilla Foundation suggests that there is some way to go before a hard-fail approach can be enabled by default.
Despite the drawbacks of soft-fail OCSP checking, there are circumstances in which a soft-fail approach can still be useful. For example, it might be desirable to revoke a domain-validated certificate which had been issued to a deceptive domain name (e.g. paypol.com), or when a domain changes hands. In the absence of any man-in-the-middle attackers, soft-fail OCSP is likely to be effective.
Irrevocable certificates
Browsers that do
not support CRLs, such as Firefox, are not able to determine whether or
not the 4% of certificates without OCSP responder URLs have been revoked. Only if an OCSP response has been stapled to the TLS connection can such browsers check the revocation status. Given the majority of certificates (76%) are served without a stapled OCSP response, such certificates are effectively
irrevocable for a large proportion of internet users. As a result, the
compromised certificates can be misused for fraud up until their natural expiry
dates. A smaller number of certificates fail to specify
URLs for either method of revocation,
which makes them completely irrevocable in all browsers which rely on
these technologies.
It is likely that browser vendors will be forced to take additional steps to
ensure that irrevocable certificates are correctly regarded as invalid. Such
measures were taken in 2011, when Mozilla released new versions of Firefox which
explicitly blacklisted some of the
fraudulent certificates generated by the
Comodo Hacker, even though the affected certificates had already been
revoked by the issuer. One of the fraudulent certificates
released to the public impersonated Firefox's addons site at
addons.mozilla.org. Google's CRLSet gives it the ability to distribute such revocations without relying on any certificate authority to revoke the certificate.
Accenture was using a CRL-only Extended Validation certificate on its website at https://apps.accenture.com using a vulnerable version of OpenSSL (1.0.1e). The potentially compromised certificate was subsequently replaced with a new certificate issued on 14 April, and the
previous certificate (serial number 0x0100000000013b03d6adfeff5c37) was revoked. The serial number was added to the CRL at
http://crl.omniroot.com/PublicSureServerEV.crl.
If an attacker had managed to compromise the private key used
by the old certificate, he can continue impersonating
apps.accenture.com with a seemingly valid SSL certificate until its natural
expiry date in November 2014 for victims using browsers which do not check CRLs, which includes Firefox 28. The only indication that revocation checking has not been completed is the lack of the EV browser cues. This certificate is present in Google's CRLSet, and so Google Chrome users are protected against its misuse.
A currently deployed EV certificate without OCSP in Firefox 28 (left). The EV browser cues are not displayed in Firefox as the revocation status has not been checked. Internet Explorer (right), which has checked the revocation status on the CRL, does display the additional green bar with the company's name.
Apple's Safari web browser also does not perform any CRL revocation checks
for Extended Validation certificates despite doing so for non-EV certificates. This behaviour may be based on the Baseline Requirements and the EV guidelines, which have mandated that EV certificates contain an OCSP responder URL for some time. As a consequence, the certificate previously used on apps.accenture.com is also irrevocable in Safari. In addition, despite making no revocation checks, Safari retains the EV browser cues rather than downgrading to standard SSL.
Problems revoking intermediate certificates
Digital certificates are verified using a chain of trust. At the top of the
chain is the root CA's public key, which is built into the browser. The corresponding
private keys can be used by the root CA to sign an intermediate certificate one step down
the chain. At the very bottom of the chain is the certificate for the website
itself, which is signed by the sub-CA whose intermediate certificate is immediately above the site's certificate. A single chain of trust can have multiple intermediate certificates chained together in order to form a path from the website's certificate to a trusted root.
An example of an SSL certificate's chain. This one is used by www.mcafeecustomerrewards.com.
Browsers must trust each level of the chain: all intermediate certificates in
the chain must ultimately be signed by a root CA in order for the website's certificate to be trusted. Most root certificate authorities are understandably
paranoid about the security of their private keys, and so root certificates are rarely compromised directly. Smaller certificate authorities, however, may not have as much funding or expertise, and may be more likely to suffer from security
breaches which could result in the disclosure of an
intermediate certificate's private key.
If the private key of a sub-CA's intermediate certificate is leaked, it has serious implications for the whole internet. A
fraudster could use the certificate's private key to issue arbitrary publicly
trusted certificates, essentially allowing him to
impersonate any website on the planet. It is imperative that compromised intermediate
certificates are immediately revoked, but it difficult to
achieve this in practice.
For example, when a Firefox user visits www.mcafeecustomerrewards.com, a website which has a non-EV certificate,
Firefox will only make an OCSP request for the website's certificate. This means
that the revoked intermediate certificate (McAfee Public CA v1) will continue to be trusted by Firefox,
and the only way to resolve this would be for Mozilla to release a new version
of Firefox. The same behaviour is seen in Google Chrome unless revocation checking is enabled, as the intermediate certificate is not in Google's CRLSet. When Chrome has revocation checking turned on, the certificate is correctly marked as revoked.
The entry for McAfee Public CA v1 in http://www.rsasecurity.com/products/keon/repository/certificate_status/RSA_Security_2048_v3.CRL.
www.mcafeecustomerrewards.com uses a certificate which has been signed by a revoked intermediate certificate (McAfee Public CA v1). Firefox displays the site without showing any warnings.
Google Chrome revocation bug
Although Google Chrome does not perform OCSP checks by default, it does perform them in the case of Extended Validation certificates (unless the certificate is already covered by the CRLSet). However, the Linux version of Google Chrome does not prevent access to sites using a revoked EV certificate when not covered by the CRLSet. Despite the browser sending an OCSP request and receiving a 'revoked' response, it mishandles the results and fails to block access. Instead, the EV browser cues (the green bar) is removed. Netcraft reported this apparent bug to Google in
August 2013,
but it was classed as low severity and has yet to be fixed on Linux.
The Windows version of Chrome (on left) behaves correctly and blocks access to
a site with a revoked EV certificate. However, Chrome on Linux (on right) does not display any errors when a site uses a revoked EV
certificate; it merely downgrades the UI from EV to standard SSL.
Where can we go from here?
Each of the currently available revocation methods has significant disadvantages: CRLs are potentially very large; OCSP can be blocked easily; and CRLSets are not intended to provide complete coverage. To those looking to move towards hard-fail, despite being far from pervasive, OCSP stapling could offer the answer. When combined with must-staple, currently an Internet draft, it would enable per-site, opt-in hard-fail behaviour. However, this solution is limited by the length of time (the Baseline Requirements limit the validity to 10 days) an attacker can use a cached 'good' OCSP response saved just before the certificate was revoked.
In the meantime, CRLSets, if they provided wider coverage, would be a more robust alternative to soft-fail OCSP checking. Mozilla is also looking to join Google by move towards a CRLSet-like mechanism for some of the revocation checking in Firefox.
Even soft-fail OCSP checking can be made more robust by removing any secure indicators (such as padlocks) when visiting a site without up-to-date revocation information.