How to ensure rogue security certificates don't subvert your encryption
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 google.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.)
Mozilla's green bar. Safari displays the same information in green text at the right end of the URL field.
Let’s take a typical scenario. google 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 google.com. GeoTrust uses some method of verifying
that google’s technical chief or IT department should be allowed to receive
such a certificate, typically by sending email to a google.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,google installs it on its servers that handle secure
connections. Google.com 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 google’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 (google.com) translates into the underlying Internet protocol (IP) address
(58.2.2.1.1) 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.
A certificate that has a domain name other than the one assigned to a server feeding out a secure connection prompts browsers to provide dire warnings that can’t simply be clicked to ignore.
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 google.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 Access,
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.
Set OCSP and CRL to always check if a certificate has revocation server information, and make sure both kinds of revocation services are consulted.
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.
Firefox doesn’t allow downloading a list, but checks each certificate for revocation.
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. 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.
Perspectives tracks certificate signatures over time, and warns you if the one retrieved by your browser is different from those stored over the last 30 days by multiple notary servers.
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.
You can change the value of any built-in certificate authority to avoid letting it vouch for the integrity of secure connections.
Open the Keychain Access 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.)
You can remove the trust from any certificate authority in Firefox.
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.
Posts
