In the face of mounting evidence that the CA system is inherently flawed, Google officials are in the process of making changes to the way Chrome handles certificate revocations, and no longer will be using online revocation checks. Instead, Chrome will use the existing update system in the browser to accomplish this task.
The way that the certificate revocation system works now is that various CAs maintain services that publish lists of revoked certificates. When a user connects to a site that uses an SSL certificate to assert the security and authenticity of its site, the user’s browser will go out to one of these services and check to see whether the certificate has been revoked for some reason. If so, then the browser should throw an error, warning the user that the certificate is no longer valid.
However, as these checks are done online, there are a number of cases in which they can fail, including if the service is unreachable. So in those cases, the browser will ignore the problem and move along. This, of course, is sub-optimal for users who are interested in knowing whether they’re connecting to the online banking or shopping site they’re expecting to reach. As a result, Google is changing the system that Chrome uses for certificate revocation.
“Our current method of revoking certificates in response to major incidents is to push a software update. Microsoft, Opera and Firefox also push software updates for serious incidents rather than rely on online revocation checks. But our software updates require that users restart their browser before they take effect, so we would like a lighter weight method of revoking certificates,” Google’s Adam Langley wrote in a blog post on the changes.
“So Chrome will start to reuse its existing update mechanism to maintain a list of revoked certificates, as first proposed to the CA/Browser Forum by Chris Bailey and Kirk Hall of AffirmTrust last April. This list can take effect without having to restart the browser.”
There are various methods through which an attacker can prevent a user’s browser from reaching one of the services that contain the revocation lists, including a man-in-middle attack in which the attacker can intercept the user’s SSL session. Researchers have shown this to be possible in a number of scenarios, including the BEAST SSL attack developed by Thai Duong and Juliano Rizzo last year.
“But an attacker who can intercept HTTPS connections can also make online revocation checks appear to fail and so bypass the revocation checks! In cases where the attacker can only intercept a subset of a victim’s traffic (i.e. the SSL traffic but not the revocation checks), the attacker is likely to be a backbone provider capable of DNS or BGP poisoning to block the revocation checks too,” Langley wrote.
“If the attacker is close to the server then online revocation checks can be effective, but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed. In short, even revocation checks don’t stop this from being a real mess.”
