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.

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.

With a verifiable certificate, any seemingly secured web connection can be intercepted by a party that can insert a tap into a network point between the browser and the server. It's bad.

I'll break down the details later in this article, but the critical fact is that this was apparently discovered and contained quickly. New mechanisms that have slowly been put in place to assure the integrity of secured Web sessions (and secured email and some other services) are — well, they're actually working!

Mac and iOS users can take advantage of these easily with Safari and any major browser. If you're lucky, you'll never see an error that indicates a security connection has been redirected and hijacked. But if you do, this article will help.

Who's in charge here?

If you want the full rundown on the CA system and how digital certificates work, you can consult my 2011 Macworld article "Keep your Mac safe from Web security flaws." After nearly four years, the basic infrastructure remains the same, but all the advice has changed. Some potential future improvements disappeared or stalled, while others have moved rapidly to deployment.

The tl;dr summary is that all secure web connections rely on a handshake between a browser and a server. The browser receives a digital certificate from the server, which contains its public encryption key, details of to whom it was assigned including a domain name or names, and a cryptographic signature that's used to validate that none of the information in the certificate has been tampered with. The public key is used to protect an encryption key used for the current connection--a "session"--without requiring any other coordination between browser and server.

Several hundred entities around the world--companies, nonprofits, and some government agencies or companies closely affiliated with governments--act as certificate authorities, any one of which can sign a web server's certificate on request (almost always for a fee). A CA provides another layer of trust and verification that the security document was provided by a party that controls the domain name that corresponds with the certificate.

CAs also need to be verified, and that involves baking some of their cryptographic data into operating systems, like OS X, Android, and Windows. Many browsers consult the OS list of CAs; some browsers do not and contain their own unique CA list. You can review Apple's list of built-in CAs in OS X by launching Keychain Access (Applications > Utilities) and clicking System Roots in the Keychain list at left.

 

1  2  3  4  Next Page 

Sign up for CIO Asia eNewsletters.