By now, a lot of the internet has heard about the recent SSL exploit, including stints on Digg and Slashdot. One thing I haven’t seen so far is a simple summation of what it is and what it allows.

What it is

SSL certificates work through a chain of trust. Your browser gets Certificate A from a secure website. Certificate A was signed by Certificate B, Certificate B was signed by Certificate C, and so on. The chain of trust looks like this:

  • Certificate C (Root Certificate)
    • Certificate B (intermediate Certificate)
      • Certificate A (www.somedude.com)

You can have multiple intermediate certificates, but eventually they all lead back to one root certificate. If that certificate is one that is ‘trusted’ by the browser, then the whole chain is trusted. This is accomplished by shipping a list of default certificates with the browser or the operating system itself (or both).

The reason you can trust this chain is because not every certificate can be used to create (or ‘sign’) other certificates, so a large company like Verisign can sell you a certificate and sign it, but they won’t grant you the same ability to do so for others. In other words, C vouches for B, B vouches for A, but A can’t vouch for anyone else.

The exploit works by essentially ‘faking’ this trust, creating a duplicate Certificate A that looks legitimate, but which was created by an attacker. This certificate can be created in such a way that it can take part in the chain of trust, and vouch for others. It’s much akin to getting someone to sign a cheque, then bleaching off the numbers and replacing them with much larger numbers. The chain of trust then looks like this:

  • Certificate C (Root certificate)
    • Certificate B (Intermediate Certificate)
      • Certificate A (www.somedude.com)
      • Certificate Z (fraudulent Intermediate Certificate)
        • Certificate Y (www.bankofamerica.com)

What it allows

Because Certificate Z in the example above is an intermediate certificate, it can ‘sign’ (vouch for) other certificates, which opens up a huge can of worms. Here are some simple examples of what you could do with it:

  1. Create a fake certificate for www.bankofamerica.com or www.paypal.com, then create a fake website with a login form. The browser believes that the site is secure and trusted, and there is no way to tell the difference. The attacker can then use any one of hundreds of different ways to redirect people to their own site instead of the bank’s and start trapping people’s passwords.
  2. Sign certificates for other people. Think about this one – why bother going to the trouble of faking a website at all, when there are thousands of people out there who would be happy to pay you thousands of dollars to issue a fake certificate. You’re essentially making fake IDs for anyone with cash up front. It doesn’t cost you anything to do, you can do it in seconds, and people will pay tens of thousands for the privileges, in return for the opportunity to make even more. If you don’t get greedy, you can make out like a bandit.
  3. Codesigning. You can issue yourself code-signing certificates, so that when someone accidentally loads your Java applet or ActiveX control, they’re presented with a little dialog saying ‘This applet was signed by Microsoft Corporation, are you sure you want to run it?’ Any users who see that will just click ‘ok’ because hey, who doesn’t trust Microsoft? Likewise, you could create spyware and sign it as being from Microsoft, Apple, or whoever, and people will trust you.

Imagine if you had a way to print passports that 99% of people couldn’t tell were fake. Passports, driver’s licenses, SSN cards, or any other ID you wanted. You create a driver’s license and passport with your picture and someone else’s name, and clean out their bank accounts. Pretty powerful, eh? Now imagine that you could sell the same ability to other people. How much money could you make then?

Now imagine that, because it’s all digital, you can do this to a hundred thousand bank accounts every day.

Preventative measures

Unfortunately, there’s nothing you as a user can do, other than being vigilant. Watch out for unusual behaviour, and be wary whenever an e-mail or website tells you it needs personal information. PayPal, for example, will always address you by your first and last name, and they will never include a link in an e-mail. If they ever need you to visit their website, they will tell you to do so, but leave it up to you to visit the website on your own. Any responsible bank or financial institution should do likewise.

The only thing that can be done now is for SSL certificate issuers to stop using the MD5 algorithm to sign certificates – this is the weak point, and this is a simple fix – three hours after Slashdot first posted about the vulnerability (at 9:30 in the morning) Verisign had solved the problem. In a perfect world, everyone would have patched this hole by now, but chances are that it will remain a possibility for quite a while.

Hopefully the straggling institutions who are too stupid to solve this problem will have their own certificates revoked, which will instantly and completely destroy their business. One can only hope.

Update: Read Tim Callan’s blog post on the topic to see Verisign’s (admirable) response.