Certificate authority trust breach exposes vulnerability in Internet’s trust hierarchies

DevBlog

10 years ago

In late March 2015, there was a major security breach involving unauthorized digital certificates impersonating Google. This incident has far-reaching implications for how ordinary people decide who to trust on the Internet.

In this post, we’ll try to explain why this matters to end users like you.

What happened, in a nutshell

Google detected high quality forgeries of SSL certificates for Google domains. The forgeries were so good that they could trick most browsers, possibly letting an attacker impersonate Google and other domains, potentially even tricking users into revealing their passwords. Thankfully, the forgeries only existed within a closed test environment.

Issuing such fake digital certificates—even in a testing environment—is supposed to be almost impossible, thanks to the rigorous processes in place to verify the identities of the certificate holders. The fact that this happened is therefore a very big deal, and it means that it can happen again, and that it has probably happened before for other organizations but went unnoticed.

Google is responding by updating its Google Chrome browser to no longer trust the specific certificate authority involved (called CNNIC); it’s removing the CNNIC’s root certificates from its products. Mozilla (creator of Firefox) will distrust all new CNNIC certificates until CNNIC’s successful reapplication for inclusion in its root store.

Refresher: Here’s what happens when you visit a site with a valid SSL certificate

It’ll help to have a high-level understanding of what happens when we go to a website using https and our browser shows us a green checkmark or lock saying this site is secure.

You type https://www.google.com into your web browser.
Your web browser accesses a public directory called DNS to look up which IP address it should use to contact google.com.
Your web browser contacts the server at the IP address it received from DNS.
The server responds with an SSL certificate.
Your web browser uses this SSL certificate to achieve two very important things:
1. It confirms the identity of the server. In this case, it confirms that the server is really run by Google; and
2. It sets up an encrypted communication channel, so that data sent between the browser and the server are encrypted. Whoever listens on the network can see that you’re communicating with Google, but cannot look inside the contents of your communication.

If the SSL certificate is valid, your browser will show the familiar green checkmark or lock on the address bar.

Ahh, the green lock.

However, if an attacker managed to trick my browser into contacting a fake server, your browser will notice that the SSL certificate is invalid, and it will show you a security warning.

Here’s what happens when the SSL certificate is a high quality forgery (hint: your browser won’t notice)

Here’s why the announcement from Google is so important: MCI Holdings managed to create fake SSL certificates for Google that were so realistic that it could trick most web browsers into thinking that a website on a fake server was actually Google. This should ideally never happen. But when it does, this is what it would look like:

You type https://www.google.com into your browser.
An attacker tricks your DNS server into giving you the wrong IP address for google.com. They could do this by exploiting bugs in your home router, other routers in the network, bugs in the DNS server itself (typically run by your ISP), or various other ways.
Your web browser contacts the fake server.
The fake server responds with a bogus SSL certificate. However, the certificate is such a high-quality fake that your browser thinks it’s valid.
Your browser will show the green checkmark or lock in the address bar.
1. When the SSL certificate is a high quality, undetectable forgery, you and your browser will think it’s actually GMail…
You type your Google username and password into a high-quality clone of GMail, thereby sending it to the attacker, who now gets control over all your Google data including your email, documents, photos, contacts, and anything else tied to your Google account.

How do web browsers decide whether an SSL certificate is valid, anyway?

Each operating system, smartphone, and web browser comes pre-installed with a list of a few dozen companies or governments whose digital signatures it will automatically trust, unless configured otherwise (more about this later). These trusted companies are called Certificate Authorities, or CAs, and must meet detailed criteria in order to be a part of that list.

You can access this by going to Spotlight > Keychain Access > System Roots.

If a website presents a certificate that is signed by any of these trusted certificate authorities, web browsers will interpret that as “I see the signature of this certificate authority that I’m pre-configured to trust. It has signed the certificate of this server. That means it has verified the people behind that server and confirmed they really are who they claim to be. Therefore, I’ll trust this certificate as well, and show the green checkmark or lock to my user.”

It helps to think of certificate authorities as analogous to the central trusted bodies that issue identity documents like passports. When you apply for a passport, you need to bring supporting documents like your birth certificate, your driver’s license, and a photograph, and you probably have to do it in person so they can verify that you are the person in your photo. When you travel, you use your passport as your identity document. Governments, hotels, and airlines trust that you are the person that your passport confirms you to be.

You can think of a certificate authority as analogous to a passport-issuing office, and you can think of a digital certificate as a kind of passport, or identity document, for a website. Passports are (ideally) difficult to forge, and have expiration dates. In the same way, digital certificates should (ideally) be difficult to forge, and they also have expiration dates. Past the expiration dates, passports and digital certificates become invalid.

We can’t take who our browsers and computers trust for granted

You might be familiar with some of the certificate authorities that your computer is automatically pre-configured to trust, like Symantec and GoDaddy. But did you know that your operating system or browser probably include root certificates for far-flung organizations like the Hong Kong Post Office, an organization from the Netherlands called Staat der Nederlanden Root CA, and various governments around the world? (If you’re curious, here’s list of organizations trusted by Firefox).

The risk is what happens when one of those certificate authorities signs a forged certificate from an impersonator through negligence (which is what seems to have happened with the CNNIC/MCS Holdings/Google debacle), or potentially even through malice.

Is it time to reconsider who we trust on the Internet?

Trust on the Internet flows transitively. We trust the developers of our operating systems and our web browsers; we trust the companies like Google that handle our data on the Internet; and we trust several certificate authorities to carefully verify the identity of various websites and only issue SSL certificates to their legitimate owners.

The case of the forged Google certificates highlights the importance of reviewing which certificate authorities we really need our browsers to trust. Depending on which websites you typically visit, the set of certificate authorities that you actually rely on might be much smaller than the set that is pre-trusted on your computer.

Here’s what you can do about this:

Consider disabling some of the root certificates that came pre-configured on your computer. For example, if you don’t typically browse websites in the Netherlands, it’s probably wise to disable the authority called “Government of The Netherlands, PKIoverheid” that your browser is probably set to trust currently. We also suggest disabling the root certificate for CNNIC.
Consider making Chrome your default browser, since Google has a track record of being vigilant and responding promptly to trust breaches.
Follow projects like Google’s Certificate Transparency Project, which is creating a technical solution to notice forged certificates faster. Over the coming months and years, such projects will create plugins and improvements to browsers and operating systems to solve some of these problems, but those solutions aren’t fully available today.
In the meantime, remember to use a VPN. It protects you from some of the possible ways in which an attacker could try to use a forged SSL certificate on you. For example, the VPN makes it a lot harder for an attacker to tamper with your DNS results.