Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Private I: Trust and verify for network certificate roots

Glenn Fleishman | March 27, 2015
In a post on March 23, Google's security team explained that it had discovered that someone was delivering digital certificates to users for Google domains that weren't authorized by Google. A quick investigation discovered that a Chinese certificate authority (CA), CNNIC, had improperly given a reseller enough power to create verifiable certificates for any domain in the world.

When a browser receives a certificate that can't be verified, the connection fails and a user is warned. That's one category of problem which you may have seen. It usually comes up accidentally, when a server is misconfigured or a certificate wasn't created that includes all the domain names being handled by a given server.

But the other scenario, which I talked about in 2011, occurs when a legitimate, verifiable certificate is issued by a CA or one of its affiliates inappropriately. (Most CAs have reseller programs and allow third parties to sell certificates that are processed through a connection to the CA's back-end systems.) Sometimes it's an error, sometimes it's a bad judgment, and sometimes it's due to an attack on the CA or its affiliate.

In the case highlighted by Google Security, the root CA gave its reseller the keys to its kingdom: a private key that allowed the creation of a certificate that would work for any domain. This affiliate installed this into a data inspection device, often used in corporations and by governments to sniff secure data that passes across or between networks.

The legitimate use of this is in companies or agencies that disclose the behavior to employees because they have a need to scan for misuse of information or security leaks. A proper configuration involves configuring individual machines before they can use the network with a local certificate or proxy settings that allows this inspection.

What CA's reseller did is now banned by all OS and browser makers as of a few years ago: installing a generic matches-everything certificate that can intercept all data, because that same certificate could be used anywhere in the world.

We don't know precisely what triggered Google's alert, and the company didn't reply in time for this column to a query for more details. But based on its report, it was likely that users in the affected company or location who used Chrome received errors and reported those to Google. This will soon be a much more widespread option for more domains, and the warnings now appear in almost all modern browsers.

Pin the tail on the certificate

When a bad certificate is issued by any means, CAs should be able to issue a revocation--an automated "statement" of badness that's sent out and consulted by any browser or other software before it accepts a certificate from any server.

In Keychain Access, in Preferences under the Certificates tab you can see (and set) the ways in which revocations are handled. Without getting into the weeds, the process isn't considered reliable. Revocation servers aren't always available, and if they aren't, the lookup either locks your browser up or times out and accepts the certificate whether it's revoked or not! (There's a new way to manage revocations that's gaining ground, but it's not widespread enough to rely on yet.)

 

Previous Page  1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.