Chrome turns its back on security 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.

Google cites a number of reasons for getting rid of CRL and OCSP checking:

• Revocation checking doesn’t work because revocation links aren’t included or the revocation sites aren’t available
• Revocation checking doesn’t work because the browsers can’t or don’t enforce it
• Revocation checking is a significant security vulnerability because attackers can intercept a revocation check and cause a fake failure that the browser will ignore
• OCSP is slow, often adding up to a second to the website connection process

I don’t buy the “revocation checking is too slow” argument. It’s already being done on every single HTTPS-enabled website visited, and even though it might fail, the time to check is already allocated. More to the point, I don’t know a single user complaining about slow connections to their HTTPS-enabled website. Plus, once you’ve visited a website that uses a digital certificate, the revocation check is cached, often for many days, so that subsequent visits don’t undergo the same revocation check until the cache entry expires.

Nevertheless, Google is more concerned about the current revocation checking process not working and not having real value. Its fix is to replace online revocation checking with a local revocation list in Chrome that is updated as needed. The Chrome browser will check the local list each time revocation checking is needed. In order for this to work, digital certificate issuers (or trusted third parties) will need to send lists of revoked certificates to Google whenever new ones are added.

A few Internet browsers, including Chrome and Internet Explorer, already use local revocation lists. Microsoft uses both local and remotely checked revocation lists. What is changing is the fact that Chrome will no longer use the remote methods for standard revocation checking, although it may continue to do so for the more highly trusted Extended Validation (EV) certificates. Further, the updates to the local revocation list will be able to take effect without restarting Chrome; currently a restart is needed for the new local revocation list to take effect.

Google’s decision is disruptive in a number of ways. Chrome will be the only major browser that uses local revocation checking alone, departing from the industry standard. Google will have to make sure that revoked certificates are added promptly to its local lists to remain effective. This will put the burden on each certificate issuer to notify Google directly (using a custom format and procedure) to assure that Google blocks the certificate. Finally, Chrome’s local revocation checking is being implemented in a nonstandard way, so there is no assurance that other applications will be able to use the updated list.

Certificate revocation checking: A simpler fix The last two outcomes bother me the most. Requiring each issuer to notify Google directly means certificate issuers must support at least two revocation notification pathways: one just for Google, and the normal, standard method for everyone else. It’s double the work at the very least. If every browser, OS, application, and service vendor decides to follow Google’s lead, then it will quickly multiply the number of notifications, each with its own procedure and format. What’s to stop Facebook, Twitter, or any other service with sufficient clout from requiring its own revocation checking method, now that Google has dismissed the current method as broken?

The current process is broken only because browsers do not enforce revocation checking, and there are no consequences for failure. If the major browser vendors forced revocation checking and blocked on failure as the protocol inventors intended, most revocation problems would disappear almost overnight. The only reason digital certificate issuers get away with poor implementation is that the browsers don’t enforce revocation. If the browsers did their job, the users who rely on digital certificates would force the certificate issuers and owners to fall in line.

I understand that the real problem is with consumers. A few years ago, during a major Firefox update, when the Firefox browser all of a sudden enforced revocation, Mozilla received a hailstorm of complaints that forced the company to reverse the decision. The same thing happened to Microsoft when it tried to enforce certificate revocation in Internet Explorer. It “broke” websites, pissed off customers, and drove many users to alternative browsers.

If consumers demanded that PKI worked like the inventors said it would, they would demand that revocation checking be enforced. Digital certificate issuers, hearing complaints from users and websites, would fix errant certificates and revocation pointers.

That is my main problem with Google’s decision. The current process works, or would work, if we’d use it as intended. Abandoning online revocation checking for an entirely new process will only lead to varying standards, confusion, and multiplication of effort. The inventors of PKI understood this. It’s why they created a standard way for checking revocation information. Plus, we have existing PKI standards such as OCSP Stapling and Strict Transport Security that can be used or extended to overcome the problems Google is trying to escape.

I don’t blame Google for feeling compelled to protect its customers as quickly as it can. Fixing existing protocols is a very long process, often measured in years. Still, there is a better solution than the one Google has proposed. I’d much rather see the major browser vendors coming together and agreeing on a common enforcement date. Give the major certificate issuers and owners a set period of time to get their houses in order, then enable enforcement of revoked certificates. General industry agreement would protect the largest number of consumers with the least amount of work. It’s a “kumbaya” opportunity that doesn’t require proprietary mechanisms or reinvention.

This story, “Chrome turns its back on security standard,” was originally published at InfoWorld.com. Keep up on the latest developments in network security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.