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
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
verification checks done – no control validation – no subscriber agreement
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).
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.
to post comments)