Last October, we published a three-part series on SSL certificates: what they are, how they work, and how they’re used to secure transactions over the Web. You’ll find the series listed in our “Security” category. For most of us, this process has worked pretty well for a long time. But I recently ran across a paper by Christopher Soghoian and Sid Stamm that points out a vulnerability that, frankly, hadn’t really occurred to me before.
NOTE: I’ve chosen to place a copy of this paper on our own Web site, because I believe that the material is important enough that I wanted to ensure that it would be available even if the link I used to find it should no longer be valid. I believe that this is permissible under the Creative Commons Attribution license cited by the authors.
As we discussed in the previous series, the security of the public key infrastructure (“PKI”) that we’ve come to rely on ultimately depends on the trustworthiness of the Certificate Authorities (“CAs”) that grant the certificates. In general, a public CA (e.g., VeriSign) assumes some responsibility for verifying the identity of the person or organization requesting an SSL certificate. The level of verification performed depends on the type of certificate purchased. A small business purchasing a certificate that will be used to secure their Outlook Web Access site can get one pretty cheaply, and typically the issuer will only require that the requester be able to reply to an email message sent to the domain in question. On the other hand, Bank of America will go through a much more detailed process to get an “Extended Validation” certificate for one of their on-line banking servers (as well they should).
But if a bad guy could somehow obtain, from a trusted CA, a certificate for a Bank of America server, and then trick a user into visiting their fake BofA Web server, there would be no easy way for the user to know that something bad was going on – because the browser would indicate that a valid SSL session had been established.
Of course, any CA that knowingly issued such a certificate would risk irreparable harm to its reputation, punitive lawsuits, and potentially have its trusted status revoked by the major Web browser manufacturers. But, as Soghoian and Stamm point out in their paper, there are no technical restrictions that would prohibit a CA from doing so. So the integrity of the entire PKI and the security of millions of users’ communications ultimately depends on hundreds of CAs around the world choosing to do the right thing.
Now, I’m not particularly worried about VeriSign or GoDaddy, because I’m pretty sure they’re not going to cooperate in something like this without a court order (more on that later). But I didn’t realize that Microsoft, Apple, and Mozilla (Firefox) all include a number of national government CAs in their default “trusted root certification authorities” databases. For example, Microsoft’s program includes the governments of France, Korea, Latvia, Serbia, Tunisia, Turkey, and Uruguay, just to name a few. I’m sure that these government CAs are included for all the best reasons. But I’m not sure that I’m particularly comfortable with the idea of having my browser, by default, trust the government of Turkey with the blanket power to issue SSL certificates for any Web site. Correction – I’m sure that I’m not comfortable with that!
Why? Because the possibility is very real that some government, somewhere, might compel a CA to issue a false certificate that can then be used to perform a “man-in-the-middle” attack for surveillance purposes. In fact, as Soghoian and Stamm point out, there is evidence that this has already been done. (If you want the details on that, read their paper.)
As a result, they are working on a Firefox add-on that is currently known as “CertLock.” Certlock will keep track of the country of origin of the root CA of each Web site you visit, and if, on a return visit, it detects that the certificate being presented chains up to a root CA in a different country, even though your browser may trust that CA, it will warn you. For example, if your banking site uses certificates issued by VeriSign, which is a US-based CA, CertLock will store that information the first time you go to your banking site. If, on some future visit to that banking site, the Web server you hit presents a certificate that – although it appears to be valid – is chained to a root certificate issued by Etisalat in the United Arab Emirates, you’ll get a warning, and a chance to abort the connection.
Is this a perfect solution? No. Admittedly there are some scenarios that won’t be caught – but those are arguably not that significant anyway, with the possible exception of #4 below. To use a few of the examples cited by Soghoian & Stamm:
- Assume that the US government compels VeriSign to issue a certificate for use by a law enforcement agency wishing to intercept communications between a suspect located in the US and his/her US-based bank, which uses VeriSign certificates on all its Web servers. CertLock won’t detect that, because the CA issuing the fake certificate is the same CA that issued the legitimate certificates.
However, if the government can get a court order compelling VeriSign’s cooperation, it could just as easily – and probably more easily – get a court order directly compelling the bank to disclose the suspect’s account information. So there’s little point in the exercise.
The same holds true if the bank’s legitimate certificates were issued by, say, GoDaddy instead of VeriSign. They’re both US-based CAs, so CertLock won’t detect the attack – but, by the same reasoning, it’s still a moot point.
- Assume that a resident of China is accessing his/her online account with a Chinese bank that obtained its legitimate SSL certificates from VeriSign. Assume further that the Chinese government is interested in intercepting the suspect’s online transactions, and compels the China Internet Network Information Center (“CNNIC” – a domestic Chinese CA) to issue a false certificate for the operation.
In this scenario, CertLock would detect the attack – although, again, it’s an improbable scenario because the Chinese government could just as easily compel the Chinese bank to provide the suspect’s account information.
- Assume that a US executive is on a business trip to China, and is attempting to access his/her gmail account from a hotel Internet connection. Once again, the Chinese government could compel CNNIC to issue a false certificate to employ a man-in-the-middle attack, since they have no leverage to compel the assistance of VeriSign, which issued the legitimate SSL certificates. This attack would be detected by CertLock.
- Assume that a Chinese executive is on a business trip in the US, and attempts to access his/her Chinese bank account from a hotel Internet connection. If the Chinese bank was using legitimate VeriSign SSL certificates, and if the US government obtained a false certificate from VeriSign, there would be no way for CertLock to detect the attack.
Since American CAs dominate the certificate market, and are used by many foreign organizations, that last scenario is far from hypothetical, and would seem to give the US an edge in potential intelligence-gathering.
So the bottom line is that the approach taken by CertLock is not perfect. But it’s a step in the right direction, and I’ll be downloading it as soon as I can get my hands on it. In the meantime, particularly if you’re interested in security issues or if your job includes security-related responsibilities, I’d heartily recommend that you download and read the entire paper. Although it’s a bit complex, it’s only 19 pages long, so it shouldn’t take you more than two cups of coffee to get through it.
