Security Certificate Revocation Awareness
Specific Implementations
How do the various desktop and mobile operating systems
and web browsers handle certificate revocation?
Why hasn't revocation been fixed?
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 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 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 currently offers the best certificate security:
Chrome has some catch-up work to do:
The OS or the Browser
Who provides the connection security?

There's a very strong argument to be made for operating systems (and not web browsers) to provide all required Internet connection security services. (Reliable and trustworthy certificate chain verification would be part of those provided services.) If the operating system provides strong security protections, then all of its client applications, including any web browsers, automatically benefit.

This appears to be the path Google's Chromium browser team decided to take. While this makes sense as the optimal long term strategy and architecture, the trouble in 2014 is that Chrome is being offered for use on both their own Android platform as well as on Apple's iOS devices and neither of them provide certificate validity verification.

The Mozilla team behind Firefox made the opposite decision. They decided to do the hard work of developing and perfecting their own connection security system. This is why Firefox offers the best security today and operates with identical high security on every supported operating system platform. This also allows Firefox to implement new standards immediately across all browsers. Firefox already offers OCSP Stapling support and it's close to adding OCSP Must Staple. Chrome, on the other hand, perversely tells its users not to bother checking revocation at all.

Consequently, for the foreseeable future, the Firefox browser will be the most secure and securable cross-platform web browser. At some point, some years in the future, once all operating systems have caught up and reached parity, Chrome will then be able to offer its users equivalent security thanks to the security of the operating systems it's running on.
Internet Explorer on Windows:
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.
Mac OS X:
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.
iOS for iPhone & iPads:
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.
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.
The Bottom Line
Given all of the above, here are the bottom line takeaways for Internet use with protection from certificate abuse: 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.

Certificate Revocation Pages:

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2016 Gibson Research Corporation. SpinRite, ShieldsUP,
NanoProbe, and any other indicated trademarks are registered trademarks of Gibson
Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy.
Jump to top of page

Last Edit: May 08, 2014 at 14:17 (1,017.77 days ago)Viewed 22 times per day