Chrome turns its back on security standard

Google is right that digital certificate revocation checking is broken, but wrong to abandon the standard

I'm still trying to wrap my head around Google's surprising revelation (in Google engineer Adam Langley's blog) that it will disable online certificate revocation checking in a future version of the Chrome browser. Standard across all the leading browsers, online revocation checking is the process of conducting a verification query of a certificate authority when presented with a new digital certificate tied to a particular website. Although the certificate revocation process is currently broken, as I'll explain below, Google's Chrome-only fix is problematic in a number of ways. And a much simpler fix -- for Chrome and every other browser -- is plain for all to see. 

When your browser connects to an HTTPS-protected website, it will examine the digital certificate the site presents, locate the revocation link pointer embedded in the digital certificate (if it exists), then query the indicated certificate authority to determine whether the certificate has been revoked by the issuer. Common reasons for revocation include a compromise of the certificate owner's private key or just periodic certificate replacement, but a certificate can be revoked for any reason the issuer chooses. I've seen certificates revoked because the owner didn't pay the issuer in a timely manner.

[ Roger A. Grimes offers a guided tour of the latest threats in InfoWorld's Shop Talk video, "Fighting today's malware." | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ]

Revocation checking allows applications such as your Web browser to make sure that the presented certificate is still valid and a reliable vouchsafe for the site you're visiting. As such, it is integral to PKI, and without it, maliciousness can occur. Unfortunately, revocation has often been neglected or ignored. Whether and how it's done is completely dependent upon the "consuming" application or system. In many scenarios, revocation checking is so poorly implemented that it's hard to say it's being performed or provides any value.

For example, the digital certificates for many websites either don't contain a revocation link pointer, or they point to a location that isn't contactable. One presentation I saw at Black Hat Las Vegas a few years ago found that more than 90 percent of HTTPS-enabled websites didn't implement digital certificates correctly. Not all of those failures were due to revocation issues, although a large number of them were.

Certificate revocation checking is broken
HTTPS revocation checking is so hit or miss that most popular browsers fail "open" -- meaning that if the certificate's revocation information cannot be confirmed, the browser will proceed as if the certificate were still valid. Worse, in most cases, the user isn't aware that revocation checking doesn't work. Many browsers can be configured to fail closed (that is, if revocation checking can't be performed, then the browser won't let the user connect to the protected website), but no browser vendor has the stomach to make this the default behavior. Many legitimate websites would become unreachable, and no browser maker wants to risk widespread user frustration.

All PKI and crypto experts understand the current problems with revocation checking, so it's not just Google. However, Google is drawing a line in the sand to protect the users of its browser by stating that today's generally accepted standards for doing digital certificate revocation, Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP), are too broken to fix.

1 2 3 Page
Mobile Security Insider: iOS vs. Android vs. BlackBerry vs. Windows Phone
Join the discussion
Be the first to comment on this article. Our Commenting Policies