This year there have been numerous reports suggesting that the fundamental security infrastructure of the Web is on shaky ground. In March we heard about a collection of stolen security certificates, and in August the release of more than 500 improperly issued certificates came to light.
Whenever you connect to a secure Internet site, your computer and the remote server need to exchange a strong encryption key in order to prevent eavesdropping by third parties. It’s a clever jig performed hundreds of billions of times a day among hundreds of millions of programs and servers–but the web of trust that makes it work is in peril like never before.
The good news is that changes are afoot to make connections safer than they’ve ever been. But until browser and operating system makers fix the teetering system, you can take some matters in your own hands to improve your own security. (If you don’t want to know this whole system works, skip the next section and go straight to our advice on how to secure your Mac.)
Trust, but verify
If you’re exchanging information over the Internet, you have to assume all communications could be monitored by criminals, trolls, and governments. How can you start this dance if you can’t be sure you’re asking the right partner to participate? The trick devised not long after Web browsing hit the mainstream in the mid-1990s was known as SSL (Secure Sockets Layer); it’s since been updated, and has a new name, TLS (Transport Layer Security).
SSL/TLS relies on digital certificates that provide the cryptographic information for a server to send a session key safely to a client. The certificate is bound to a given domain name, like macworld.com, and can’t be used at any other domain. These certificates are issued and countersigned by certificate authorities (CAs), of which hundreds exist worldwide. CAs affix a kind of permanent seal (a digital signature) to a certificate that can be checked against a list of trusted CAs built into all major operating systems, whether desktop or mobile. Some browsers maintain their own, separate lists, too. (Safari consults Mac OS X’s list, while Firefox consults an internal table.)
Safari displays the same information in green text at the right end of the URL field.Let’s take a typical scenario. Macworld wants to offer secure Web logins. It signs up with GeoTrust to receive a SSL/TLS certificate that works for any domain that ends in macworld.com. GeoTrust uses some method of verifying that Macworld’s technical chief or IT department should be allowed to receive such a certificate, typically by sending email to a macworld.com address noted in the domain’s registration. CAs may also request additional information, such as a fax of a business license or driver’s license. For “Extended Validation” (EV) certificates, businesses have to provide even more documentation about themselves, for which they are rewarded with a “green bar” that shows up in most browsers. (To see this bar in a browser, visit Mozilla’s add-on site.)
When the certificate is issued, signed by the CA, Macworld installs it on its servers that handle secure connections. Macworld retains a private part of the key, never shared with the CA, that allows it to decrypt incoming messages used to set up secure sessions. Whenever someone visits the secure site, the certificate is transmitted. It contains only public information, including a public key that corresponds to Macworld’s private one, as well as a signature from the CA that vouches for it.
A browser receives the document, and confirms using built-in CA information that the certificate was correctly signed, and thus that the public key contained in it is valid. These CA signatures are currently considered unforgeable. The browser and server can now privately exchange a long session key and use that to encrypt all the data during the session.
That all sounds dandy. Checks and balances ensure a closed loop. But the problem lies in a couple areas of trust. First, operating systems believe anything they are told about how a domain name (macworld.com) translates into the underlying Internet protocol (IP) address (70.42.185.230) used to make the actual connection. It’s easy to “poison” DNS on a local network, such as at a coffee shop, or for an entire country, such as Iran. You simply need to position bad information at the choke point between where queries are sent by a computer for the lookup of a domain name, and from where the reply is returned.
The SSL/TLS certificates are resistant to this, however. You can poison DNS, but you can’t forge a CA-signed certificate. If you visit a server that your computer has been subverted into believing is macworld.com, and it provides a certificate for another domain or one that hasn’t been signed, then your browser barfs up a message warning about the mismatch. These warnings typically require serious effort to bypass, as opposed to the usual “horrible security flaw: click OK to continue” sorts of messages.
Since CAs control the issuing of certificates, this shouldn’t be a problem–if we could trust every CA equally. Over 600 parties worldwide act as a CA for at least some combinations of browsers and operating systems; Apple’s products honor nearly 200. Every CA can sign off on any domain, and can delegate authority to lesser parties. A security document created by any of these anointed or delegated CAs will look legitimate to all browsers worldwide.
If a CA is subverted or issues a certificate under duress because a government demands it, and a network (whether cafe or country) has poisoned DNS, the entire transaction looks legitimate to a browser. The machine swears it’s a Gmail server and it has a validly signed Gmail certificate from a trusted CA. Thus, the browser doesn’t squawk.
This is the root of all of those scary news stories about rogue certificates. In the last year, several CAs have been compromised, some potentially by government-sponsored crackers. A major certificate issuer, Comodo, had a breach through an affiliate in March, leading to valid but illegitimate certificates being issued for domains controlled by Google, Skype, Yahoo, and others. In August, the Dutch CA DigiNotar was found to have issued over 500 improper certificates, including one for all google.com domains, without providing proper disclosure nor keeping good records. There are almost certainly more revelations to come.
When a bad certificate is issued, whether an improper one such as the examples above, or one simply created with the wrong details in an administrative error, a CA can issue a revocation that is supposed to block browsers from accepting a certificate as valid. But revocations aren’t typically built into browsers or operating systems. To check whether a certificate remains valid, a browser or other software has to communicate with a CA’s revocation servers to either ask about that particular certificate or download a full list of revoked documents. Those servers may be easily blocked by malicious parties or nations–or simply not provide a response fast enough for the client software’s liking. Browsers and Mac OS X are configured to ignore an inability to check whether a certificate is revoked, rather than to make a stink about not knowing the answer.
Because of this, Apple, Microsoft, Mozilla (Firefox), and other operating system and browser makers released updates both to block specific certificates hijacked from Comodo, and to remove DigiNotar from the CA list entirely for desktop systems.
Secure yourself
So what can you do to prevent your Mac from being the subject of a man-in-the-middle snooping attack? Plenty.
First, turn on revocation checking in Mac OS X and in your browser. This may cause some disappointment on slow networks when a CA’s revocation servers aren’t as responsive as they should be.
For Mac OS X as a whole (including Safari, Google Chrome, Mail, and other programs that use secure connections), you need to use the Keychain Access app, located within the Utilities folder inside your Applications folder. From the Keychain Access menu, select Preferences. Click the Certificates tab. You’ll see options you can set for OCSP and CRL. OCSP allows a brief query about a single certificate, while CRL downloads a full list if a cached one from that CA is out of date. Apple sets these to Best Attempt by default, which means a failure is ignored. Instead, choose Require If Certificate Indicates for both OCSP and CRL. Also choose Require Both from the Priority pop-up menu. (The Require for All Certificates option is available if you hold down the Option key, but that doesn’t guarantee such a server can be found if it’s not specified in the certificate. A certificate may be obtained illegitimately, but the CA that issues it will still include revocation server information.)
The only problem with forcing a check of revoked certificates is that Apple has a flaw in how it validates Mac App Store updates. With the option selected as shown in the figure below, you may be unable to perform updates through the App Store program. To fix that, launch Keychain Assistant, change the preferences to Best Attempt, update your apps, and then reset to the stricter setting. This is something Apple should clearly fix, since all the components of this situation are under its control.
In Firefox, select Firefox – Preferences, then click the Advanced icon. Click the Validation button. Make sure “Use… OCSP” is checked, and Validate a Certificate If It Specifies an OCSP Server is selected. Also check When an OCSP Server Connection Fails, Treat the Certificate as Invalid. Click OK. In using this setting for some weeks, I’ve found a handful of times I’ve had to reload a webpage to get a proper OCSP response.
Chrome has a separate option (Chrome – Preferences, click Under the Hood, scroll down to HTTPS/SSL) where you can check or uncheck Check for Server Certificate Revocation. Keep that box checked. It doesn’t appear that you can force Chrome to retrieve a list of revoked items, but the documentation is unclear, and it’s hard to rely on in practice. It relies on Mac OS X for certificate management.
Second, if you use Firefox, you can test out a new approach in validating whether a certificate is correct without relying entirely on certificate authorities. Two projects let you install add-ons that use “notary” servers that constantly retrieve certificates and keep track of the signatures on them to alert you if a certificate doesn’t seem to be correct. (For more background on digital notaries, you can read this item I wrote for the Economist.)
The Perspectives Project alerts you if your browser receives a certificate for a site that’s different than one found over the last 30 days. Convergence also relies on notaries, but over time will allow other kinds of integrity checks.
Third, if you use Chrome, Google has and continues to add additional certificate checks. The current release of Chrome only allows certain CAs to vouch for Gmail’s certificate, and blocks other attempts. Expect more along these lines. (In fact, this Chrome feature is what alerted an Iranian user to an apparent use of a DigiNotar obtained google.com certificate on an Iranian network.)
Removing CAs
So what happens if you read a news report about a compromised CA and want to pluck the CA out of your browser as soon as possible? To change Mac OS X’s settings, and thus affect Safari, Chrome, Mail, and other programs that rely on these values, follow these steps.
Open the Keychain Assistant app as before, and click the System Roots item under Keychains at upper left. Select the certificate in question from the list, and select File – Get Info. Click the expand triangle next to the word Trust near the top. From the When Using This Certificate pop-up menu, choose the item Never Trust. When prompted for a password, enter it, and click Modify Keychain (which you are prompted for just the first time). Then enter the password when prompted and click Change Settings. You’ll see a small red “x” in the certificate’s mini-icon.
There’s one flaw, however: Even if you distrust a root certificate, Safari will ignore this lack of trust if a website presents an EV certificate. That’s illogical, and presumably Apple will fix this bug in the future. The only way to ensure that an improperly issued EV certificate won’t be accepted even when you’ve ostensibly blocked the CA that produced it is to stop using Safari until the bug is fixed.
In Firefox, choose Firefox – Preferences, click the Advanced icon, and then click the Authorities tab. Scroll through this list to find the CA you want to remove. Select it, and then either click the Edit Trust button or the Delete or Distrust button. Edit Trust lets you retain the certificate, but disallow its use. Delete or Distrust removes all trust from built-in certificate authority information, or removes a manually entered CA. (Some companies and other entities may choose to trust a CA separately from the global chain of trust built into the browser.)
What about your phone? Sadly, you’re out of luck. The greatest disappointment in all this certificate authority nonsense is that both iOS and Android have lagged behind on dropping support for suborned certificates and hacked CAs. (Windows Phone 7 never included DigiNotar on its approved list.)
Future Efforts
You might despair after reading about the scope of this problem, and the complexity in managing some of the fixes yourself. But don’t lose hope. With the exposure of these flaws, companies that sell hundreds of billions of dollars of goods a year over the Internet are aware that they can’t allow trust to seep away. Browser and operating system developers are also moving into higher gear to avoid putting customers into compromised situations.
Built-in notary support. Future browsers could include the kind of checks that Perspectives and Convergence offer. Better, you might be able to choose the notary servers you trust, so that you can place your faith in the security of particular organizations. The Electronic Frontier Foundation, which has conducted certificate research, could offer a notary service, for instance. The more notaries, the better, as it increases heterogeneity, which improves the chances of problems being spotted instantly.
Domain pinning. You may see browsers including more support for domain pinning, which allows only specific CAs to vouch for a given domain. Google built in a fixed pin for Gmail’s certificate into Chrome’s recent releases so that only three CAs are recognized as valid countersigners, and has a setting that lets you pin domains manually. One could see Apple, Microsoft, Mozilla, and others pinning domains that relate to their own businesses, and working with other companies and organizations to support a global pinned directory. This tremendously reduces the risk of rogue or suborned CAs.
Fewer CAs. It’s very likely that fewer and fewer CAs will be given the blind trust currently offered. Fewer CAs lead to a smaller risk profile and less exposure.
DNSSEC/DANE. A complicated effort is underway that will allow websites to put digital signatures for their certificates into secured DNS (Domain Name System) records. DNS is used to connect a domain name to a machine-readable IP address, and a decade-long effort to provide a cryptographic underpinning (to kill DNS poisoning, among other matters) is nearing fruition.
Dynamic CAs. Microsoft chose to use dynamic lists of CAs starting with Microsoft Vista. It’s also found in Windows 7 and Windows Server 2008. Instead of having a fixed list of CAs that an OS update is required to modify, Microsoft only caches CAs temporarily, for seven days, using a secured service it operates. On visiting a secured website, if the CA that signed its certificate isn’t cached, Windows consults Microsoft’s list, downloads the validation, and then affirms the website’s certificate. Microsoft was able to dump DigiNotar right away, while Apple took weeks to push out a security update that took care of the problem.
These fixes could all have been in place earlier. But it’s the same motivation that puts a traffic light at an intersection only after pedestrians are repeatedly hit by cars. Late–but better late than never.
View full post on National Cyber Security
