SSL man-in-the-middle attacks

A while back, we looked at the new Firefox 3 warnings for self-signed and expired SSL certificates. As annoying as some found those to be, it certainly increased the visibility of "invalid" certificates. Those certificates could lead to man-in-the-middle attacks, which is what led Mozilla to issue such eye-opening warnings. More recently, Eddy Nigg of Startcom—issuer of free SSL certificates—found another way to do man-in-the-middle attacks without setting off any of the new warnings.

What Nigg found was that he could get a perfectly valid certificate for a domain he did not control: in this case mozilla.com. He could then masquerade as the secure Mozilla site with impunity; any browsers that landed there would verify the certificate as belonging to mozilla.com. He did it through a Comodo reseller with no questions asked: "Five minutes later I was in the possession of a legitimate certificate issued to mozilla.com – no questions asked – no verification checks done – no control validation – no subscriber agreement presented, nothing."

That is clearly a bug in the verification process, but it is completely out of the control of the browser. The browser must trust some set of key signing authorities (i.e. Certificate Authorities or CAs), but has no way to control how well or poorly they actually vet the keys they sign—or their downstream resellers sign. We saw the same potential problem in a slightly different guise with "Extended Validation" certificates back in 2006. It all comes down to trusting CAs.

Sometime after Nigg's story hit Slashdot, Comodo revoked the certificate, which did cause Firefox to put up an error and disallow the connection. One wonders how many bad certificates have been issued but not revoked because a phisher or other scammer received them. One would think those folks would be less likely to publicly announce what they had done.

Bringing attention to the problem will likely help, but there are just too many ways to create bad SSL certificates for those that really want them—bribing CA employees if nothing else. Another useful outcome is that Richard Bejtlich got interested in just how the revocation process works. He collected packet data from accessing Nigg's certificate after it had been revoked which gives look inside the Online Certificate Status Protocol (OCSP).

OCSP is designed to do just what it did, cause a bad certificate to fail when verified by the browser. Nigg's certificate listed an OCSP server that should be consulted. Because that information has been signed by the CA, it can't be tampered with. So long as the browser makes the OCSP check, certificates can be revoked in this manner—as long as the CA is aware that revocation is needed.

Public key cryptography—the basis of SSL and many other encryption schemes—is an amazing method for doing encryption, but it does suffer from a major shortcoming: key exchange. For relatively simple situations, where both parties know each other and have a way to securely exchange keys, it works well. When trying to handle other kinds of communications, either a "web of trust" (a la PGP and GPG) or some kind of trusted authority is required. When those break down, man-in-the-middle and other scams are possible.