Trust Chains in SSL: Distributing Identity Verification

Knowing with whom you're dealing is an important part of any transaction, and it has been since time immemorial. Over the years, we've developed a variety of ways to verify one another's identity, with varying levels of rigor.

Identity Verification in the Non-electronic World

You're probably familiar with a lot of the ways that we verify identities outside of the electronic world. In cases where there's little to lose if we're misled and/or the other party has little to gain by misleading us, we just tell each other our names and just assume that the person is who they say they are. When the stakes get a little higher, we look to our friends to verify someone's identity, for example by introducing us in person. At the highest level of rigor, we require formal identification, usually from some entity like the government (for example, requiring a person to show their driver's license or passport).

From these ways of identifying one another, we've already seen examples of both federated trust (I trust you are who you claim to be because my friend said that's who you are and I trust my friend) and using a trusted third party (I trust you are who you say you are because the government said you are). It probably doesn't come as a huge surprise, but we end up using both in the electronic world.

Moving to the Electronic World

Verifying an entity's identity in the electronic world poses some new challenges; after all, you can't exactly ask a website for its driver's license! To deal with that, a standard named x.509 was co-opted and combined with SSL to allow websites to verify their identity. x.509 is basically a way of tying an identity to a public key (here's my previous post explaining how SSL works, including info on public & private keys). To make it work, an x.509 certificate combines information identifying an entity with a public key (and more information as well, but that's the relevant bits), then takes a secure hash of that combination and encrypts it with the private key that goes with the public key in the certificate. Taking that hash and encrypting it is known as signing the certificate, and a certificate that is signed by itself is called a self-signed certificate.

A self-signed certificate allows a web site to say who it is, with exactly the same level of assurance as a person just telling you their name. Considering we don't trust that level of assurance in important interpersonal dealings, we certainly don't trust it on the internet. To meet the need for a higher level of assurance, we have certificate authorities (usually just referred to as a CA). The service that a CA provides is that they'll sign your certificate for you, asserting that you are who you claim to be; they're basically filling the same role as the government does with the IDs that they provide. When you connect to a site that's providing a certificate signed by a CA, your browser verifies that the site has the private key tied to that x.509 certificate (as part of the SSL handshake) and then verifies that that x.509 certificate was signed by the CA.

If you need to identify a lot of servers, e.g. you're a large corporation that needs to secure email servers, web servers and database servers, it can get very inconvenient (not to mention costly!) to send off to have each certificate signed individually. To deal with that, you can get a certificate that lets you act as the trusted third party that verifies the identity of a set of servers. For example, if you're in charge of example.com, you can get a certificate that would let you sign the certificates for smtp.example.com, pop3.example.com and www.example.com as if you were a CA. If you then hits www.example.com you'll get a certificate from www.example.com that's signed by example.com, which is then signed by a CA. You then verify that certificate by walking back up the chain, verifying each certificate until you get to a root CA. This is called a trust chain and is the internet equivalent of a friend that you trust introducing you to someone and telling you that you can trust them to introduce you to other people.

Who Gets to be a Certificate Authority?

In the real world, it's relatively easy to figure out who will be accepted as a central entity for verifying identities. Governments give ID cards and we (usually) accept that they're a legitimate authority to verify someone's identity. We also have a a parallel to trust chains in the form of ID cards from universities, employers, etc, where we trust that they have verified a person's identity, at least in the context of the verifier. For example, if someone has a college ID, we assume that they have been verified as students at that college.

In the electronic world, we have root certificate authorities. Your web browser comes with a lot of them, some of them you may trust, others you may not, many you'll never encounter being used in your day-to-day browsing. You can add CAs to your list of trusted authorities or remove them as you see fit, though most people just accept the browser vendor defaults. Being in the default list of trusted certificates makes those CAs de facto trusted third parties for verifying identities.

Breaking Chains & Violating Trust

There's a good chance that you've heard about Superfish, the malware that shipped on some Lenovo laptops. Superfish installs a proxy (a piece of software that sits between your browser and the internet at large) that intercepts your web traffic to inject advertisements into sites that you visit. Normally, TLS (the successor to SSL) would protect you from software like that, but Superfish installs its own certificate as a root CA. Since it makes itself a root CA, Superfish is able to generate a certificate for any site that you visit and sign it so that it appears to be a legitimately signed certificate, prompting absolutely no warning from your browser.

On its own, Superfish is annoying and potentially dangerous if their ad server was compromised, but design errors make it exponentially worse. Superfish uses a single signing certificate for all installations. That means that if anyone gets their hands on that certificate, they can intercept and modify the web traffic of anyone with the software installed on their computer. That means they could easily get the passwords to your email, social media sites and online banking accounts. Even worse (yes, amazingly, it can get worse!) they can inject malicious content into web sites that you trust, potentially even exploiting vulnerabilities in your browser or plugins to infect your computer with additional persistent malware, leaving you even more vulnerable than before.