Internet engineers say “there's no demand for it,” and we're sure that's true. But who's going to demand anything whose absence has been carefully and quietly hidden? Given the huge reaction and concern generated by the appearance of GRC's revoked.grc.com domain, which most web browsers now display without complaint, it's clear that there's no demand for it because there's no knowledge of it. Since lack of revocation isn't something that is normally seen, Internet users have trustingly assumed that “of course it works.” But support for certificate revocation has been silently dropping year by year while no one paid attention.

When GRC's revoked.grc.com page appeared, bug reports were quickly submitted by people worried that their browser's revocation wasn't working. But that's not a bug . . . that's a feature! It's an operational feature of the broken way the Internet has been limping along for decades.

These revocation pages were created to shine a bright light on the
problem, explain it clearly, and create a demand for this to change.

Some of the terms used on this page will be more easily understandable once you have read the OCSP Must Staple page. One of the reasons certificate revocation has been stuck in the mud for so long is that it is complicated. But it is not too complicated for you. You can understand every nuance of the problem. And if you're a person who enjoys understanding things, you're going to love that page.

• Firefox is the only cross-platform browser that includes its own mature certificate verification technology. Chrome and Opera have both abandoned theirs. This means that, unlike Google's Chrome browser, Firefox's operational security is not limited by features of the underlying operating system platform. For example, when running on Android today, Google's Chrome browser performs no revocation checking of any kind. Even Google's own CRLSet system is completely nonfunctional. Chrome depends upon Android to provide connection security information. Firefox does not.
• Firefox, like Internet Explorer, Safari & Opera, enable certificate revocation checking by default. Thanks to “the tyranny of the default,” (which, in these browsers works in favor of safety) this is the setting virtually all Firefox users are using . . . because that's the way it came. Although there are ways for sufficiently well-placed attackers to defeat any fail soft mechanism, not all attackers can arrange to place themselves well. In those cases, fail soft is hard enough to stop attacks.
• Firefox is the ONLY browser to offer an OCSP “fail hard” option today. That first checkbox is enabled by default, the second one must be turned on by the user. When it is, Firefox today gives us every benefit of full OCSP hard fail certificate revocation checking. Detractors say, this may cause problems. We say, it definitely will for any attacker. Within the limits of the OCSP protocol, it cannot be bypassed, and all revoked certificates will be blocked. We have been running this way since the feature was first offered and have never encountered a single problem. (That dialog is located under Tools / Options / Advanced Tab / Certificates Tab / Validation.)
  
  Note that Windows and the Mac's OS X do offer options to enable hard fail, though they are well hidden, crash-prone, and/or require manual registry editing. See below.

• Chrome is not in a good place with its certificate security. The Android and iOS mobile operating system platforms offer Chrome no certificate security, and the desktop operating systems provide weak security at best.
  
  

  Android:	No revocation checking of any kind available on Android.
  iOS:	No revocation checking of any kind available on Android.
  Windows:	• Provided by OS	• Disabled by default	• Not enforceable.
  Mac OS X:	• Available	• Disabled by default	• Not enforceable.
  Linux:	• Available	• Disabled by default	• Not enforceable.

  
  
  The same table for Firefox would show “Revocation checked, enabled by default, enforceable.” for every operating system where Firefox is available. iOS provides revocation checking for extended validation (EV) certificates (only) to Safari and the LastPass Tab browser. But surprisingly, on iOS Chrome is even blind to that.
• Chrome's revocation checking is DISABLED by default. Thanks to the law of “the tyranny of the default,” this is the setting virtually all Chrome users will have . . . because that's the way it came. Chrome is the only web browser to disable certificate checking by default. Why? Everyone knows that Chrome is a speedy web browser. But very few know that this was a bargain made at the cost of security. Chrome's engineers recommend to disable revocation checking because “all it does is slow things down.” They will be right . . . until they are very wrong.Whoa! It just got even worse. On May 7th, 2014, the Chromium (Chrome) developers decided that the checkbox option was confusing to users (see near the end of this page). So, to help the poor confused users, they first left Chrome's external revocation disabled and have now removed the option to enable it. If you cannot find the checkbox to enable external revocation, that's what happened to it.

  If you haven't yet seen it, the official association of certificate authorities, the CA Security Council, is also quite unhappy with Chrome's CRLSet operation and decisions to disable external revocation checking.

  Note that on Windows, where Chrome relies at least in part upon Windows' underlying connection security, some revocation checking is performed even when Chrome is told not to check for server certificate revocation. Chrome does issue an OCSP stapling request in its connections. So it might be that when an affirmative revocation is returned from a connection, Chrome at least doesn't ignore that.

• Chrome lacks any enforceable “fail hard” option. Chrome has “work to do to catch up” because the industry is moving inexorably toward enforced verification of certificate revocation checking and Chrome engineers appear to be dragging their feet and fighting this every step of the way. Eventually, Windows may provide this for Chrome (whether Chrome wants it or not) since Microsoft will build this in for Internet Explorer. Apple is likely to offer it for their iOS and OSX operating systems. So, again, Chrome may get a free ride there. But it's unclear what solutions will be available for Android and Linux, neither of which appear to have anyone who's taking responsibility.

Since Internet Explorer is not cross-platform and runs only on Windows, Microsoft has been able to take a different approach with IE. The connection and certificate security services which Firefox bundles and brings wherever it runs is entirely missing from Internet Explorer because all of those services are provided by the underlying Windows operating system. The advantage is that all of these security services are available to every program running on Windows.

• Certificate revocation checked by default: As with the other secure web browsers — Firefox, Safari & Opera (but not Chrome) — Internet Explorer defaults to checking the revocation status of website certificates before allowing its user to visit.
• A deeply buried hard fail option: Like Firefox, Windows also offers the option of a hard fail notification. As with Firefox, selecting this option might result in false positive notifications (users report that Google, of all sites, seems to have the worst revocation servers). But this option will absolutely protect users from malicious certificate abuse.
  

  If you'd like to experiment with enabling Windows' hard fail policy for certificate revocation checking, these two simple registry scripts, contained within the ZIP file, will enable and disable the policy for the system's currently logged in user. They are named after the registry key that controls this optional policy: Windows_Revocation_Registry_Scripts.zip

  Even though it's well hidden, the fact that Microsoft offers “hard fail” as a supported option is good news. This means that once the industry has adopted either server- or certificate-signaled OCSP Must-Staple, Microsoft will be able to support it quickly. And Microsoft can be expected to move on this since they have been a leader in OCSP stapling on their servers (the only web server to currently have it enabled by default), and their client operating systems have also been stapling-aware for years. So everything is in place for the addition of must-staple enforcement.

• Apple's Safari browser on the Mac behaves by default much like Firefox and Explorer do by default: It checks for and blocks known revoked websites. It doesn't offer Firefox's hard fail option, but then only Firefox does currently. And none are expected to. Once web servers are able to request hard fail through the adoption of new standards, security-minded web browsers and operating systems will support it.
• Firefox on the Mac, as it does everywhere, blocks by default and allows its user to request the added security of insisting upon verification of a site's non-revoked status before proceeding. Apple's Keychain does also appear to offer a hard fail option to its applications, but reports are that this capability is unreliable and can result in system troubles. So, once again, Firefox appears to be the only reliable way to obtain full hard fail security.
• Chrome can have Safari-like revocation checking enabled. But since Chrome prioritizes speed over security under the assertion that revocation checking is pointless, Chrome is alone in the industry in disabling it by default.

Operation of Firefox and Chrome under Linux is identical to their operation under OS X: Firefox enables revocation checking by default with hard fail optional and Chrome disables all revocation checking unless or until it is enabled by its user. Apple, apparently deliberately, doesn't do nearly as well on their iOS platform as they do on the Mac's OS X. Prioritizing speed over security, iOS only checks for certificate revocation for extended validation (EV) certificates even though EV certificates are still the exception rather than the rule on the Internet. Apple may have made this tradeoff because, unlike non-EV certificates, issuers of EV certificates are required to support the OCSP protocol. So iOS may not be checking the Internet's CRL listings.

• Apple's Safari browser and the LastPass Tab browser both detect revoked EV certificates but not the revocations of any other (the majority of the Internet's) certificates.
• Chrome, surprisingly, does worse. It detects no revoked certificates even when those that Safari and the LastPass Tab browser are able to detect . . . and Chrome provides no option for enabling any detection at all. With Chrome you're truly flying blind.

The Android platform appears to be the least “certificate secure” of any of today's operating systems. Comments by Google's Chromium engineers somewhat defensively state that certificate checking is Android's responsibility, but the Android engineers must not have received that memo, because Android's Java-based programming interface has no provision for returning the required information. Although it's off-topic for this page, this also means that all of Android's applications are similarly vulnerable. We hope this gets fixed before some major breach occurs. Since the additional of a fully mature “certificate validation stack” is a huge undertaking, the situation for Android doesn't look good.

• Chrome on Android provides NO certificate revocation checking of any kind and no provision for enabling or providing any.
• Firefox on Android provides total state-of-the-art certificate revocation checking, including Firefox's ever present “hard fail” option to require an affirmative verification of a site's certificate prior to trusting the certificate and allowing connections.

Given all of the above, here are the bottom line takeaways for Internet use with protection from certificate abuse:

• Firefox is currently the safest and more securable web browser available. Use it anywhere you can (everywhere but iOS, where it's not available). Firefox now has securely encrypted cloud-sync features making it a practical browser for today's cross-platform use.
• Thanks to Microsoft's (late but welcome) focus upon security, Internet Explorer runs with reasonable security by default and hard fail revocation checking can be enabled through the registry.
• Experiment with Firefox's hard fail option. Turn it on and see whether anything breaks. “Breaks” will mean receiving site error messages when you shouldn't. We've been running Firefox that way since the option was first available and have never experienced even one problem. With “hard fail” enabled you have maximum state-of-the-art certificate protection.
• Firefox is the only safe browser to use on any Android device. Chrome provides no certificate security since they believe that it's up to Android, and Android doesn't appear to care.
• iOS is, unfortunately, nearly as bad as Android. Since Firefox is not available on iOS, use Safari with caution and avoid any use of Chrome since it's as bad on iOS as it is on Android.

The development of security always seems to lag behind the promotion of fancy new features. But it's somewhat shocking to consider the size of the installed base of Android-powered devices when you consider that Android completely ignores the entire issue of certificate revocation. And iOS is little better at the moment. The good news is, there are hard working engineers and developers who are acutely aware of the situation. They're doing everything they can to move and promote standards and to get them adopted.

A few years from now, the OCSP Must-Staple system will be adopted and this period of vulnerability will have passed into history.