Security Certificate
Revocation Awareness Test
If you can see this (and apparently you can), you
are using a revocation UNaware web browser!
The SSL/TLS security certificate for this special website has been deliberately revoked.  Since you are seeing this page, we know that this web browser is allowing a site with a known invalid certificate to display its pages. This is likely not the behavior you would choose.

Here's what we know:

  • The Firefox browser currently leads the industry in certificate revocation checking security. It incorporates its own mature internal technology and Firefox checks for revocation by default (thus protecting all users). And it does this on every operating system platform.
  • Google's Chrome browser is the least certificate-secure browser on the Internet. It puts speed before security, so it is the only browser on the Internet to disable certificate checking by default.
  • Internet Explorer uses Windows' built-in revocation checking which is also enabled by default.
  • The mobile Android platform currently offers no certificate revocation checking of its own, so Android apps (including all users of Google's Chrome browser) are vulnerable to malicious certificate abuse. The only way to use Android securely today is with Firefox, which brings along its own certificate security.
  • iOS is only a bit better than the Android disaster. It only checks for revocation of extended validation (EV) certificates and trusts everything else. On iOS, Safari and the LastPass Tab browser get this benefit. But incredibly, Chrome on iOS doesn't pay attention to any certificate revocation.

This “revoked.grc.com” test was born from the revelation of the worrisome “Heartbleed” vulnerability that had existed in plain sight for two years without public awareness in the industry standard open source OpenSSL security suite. However, this special site is about more than that:

The security of connections between devices through the Internet depends upon “authentication” (being certain to whom we are connecting in an environment where we have no direct means of verifying) and “privacy” (being certain that our communications cannot be eavesdropped upon despite the fact that our data traffic may be travelling great distances outside our direct control). Those two security properties are assured only through the integrity of the Internet's security certificate infrastructure.

“Certificates” provide a means for web servers at
the far end of remote connections to verifiably
assert their identity across the Internet.

The security certificates that routinely assure the security of our Internet connections are among the most closely guarded and protected secrets any organization maintains. Because secrets are notoriously difficult to keep, and “certificates” are just a small file of binary data, the certificates used to assert a web server's identity routinely expire every two or three years. So even if a certificate were to somehow escape, it would “die” of its own age before long. The problem is that “long” is a relative term. In a world increasingly connected by beams of light, malicious forces can wreak tremendous havoc in seconds, let alone years.

The so-called “Heartbleed” vulnerability shocked the
Internet with the specter of mass certificate theft.

The normal life cycle for a security certificate is one where it successfully remains secret throughout the span of its two or three year life. Then, as its pending self-expiration approaches, it is replaced by a freshly minted certificate with another two or three year life span. The replaced certificate is digitally shredded so that even during its last days it cannot be maliciously abused. And so the cycle repeats.

But we all know that humans, and human computer programmers, are fallible. Mistakes will happen. What if an organization came to believe, or even suspect, that their prized secret certificate might have escaped from their control? With so much riding on a simple collection of bits, the Internet's designers recognized that there were many situations, perhaps most situations, where waiting several years for a possibly lost or stolen rogue certificate to expire was not an option. The danger and risk was just too great. We needed a means for killing off (invalidating, revoking, etc.) any certificate whose owner believed, for whatever reason, that they and those relying upon that certificate's assurances might be damaged through its abuse.

So, mechanisms for certificate “revocation” were created.

And now you understand the problem . . . or YOUR problem: The fact that you are viewing THIS PAGE, which was displayed “securely” using a deliberately revoked certificate, means that this web browser is either deliberately by design, or through misconfiguration, ignoring the Internet industry's deliberately designed and otherwise functioning certificate revocation system!

This means that this web browser will not detect and warn you if you
visit a fraudulent website that is using a revoked certificate that is
known to the REST of the Internet to be bogus. YOU won't know.

At the moment, and for the next several years, this potential danger is extreme, because many experts believe that the long unseen Heartbleed vulnerability, which affected approximately 17.5% of the Internet's websites, may have been used to steal those sites' security certificates. If, upon learning of Heartbleed, those sites took the responsible action of revoking their possibly-compromised certificates and having replacements reissued, and if those stolen certificates where then used to impersonate the once-vulnerable sites, this web browser WILL NOT DETECT AND WARN YOU that you are visiting a known-fraudulent website.

By April of 2017, all of the certificates which may have been stolen via Heartbleed will have died of old age, and the threat will diminish to normal levels. But fraudulent websites are always a threat. You need to be aware, especially for the next several years, that this defective web browser is ignoring the certificate revocation mechanisms that the Internet's designers put in place specifically to protect users from the persistent threat of rogue certificates.

Good luck!

If you are interested in learning what you can do about this, and to understand more about the situation and problem of security certificate revocation, please see these pages:

Certificate Revocation Pages:

A special note of thanks to the great people at Digicert, GRC's carefully chosen and, we believe, the best certificate authority, who were gracious enough to work with us to create a special pre-revoked security certificate. Perhaps the first time this has ever been done!

Jump to top of page
Gibson Research Corporation is owned and operated by Steve Gibson.  The contents
of this page are Copyright (c) 2014 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 04, 2014 at 14:15 (351.72 days ago)Viewed 168 times per day