5
$\begingroup$

There's one thing that I've never quite understood about SSL (which perhaps means I don't understand SSL at all): how is SSL secure from rogue Certificate Authorities?

This is probably best elaborated as an example:

Suppose company B buys a certificate C from certificate authority A.

Now, normally I would go to the website, B's servers shows me certificate C, I see it's signed by A, I trust A's root certificate, everything is dandy, and off I go to throw furious avians at malicious boars.

But suppose, for whatever reason, someone M persuades/tricks a different certificate authority N to issue them a certificate Q that looks just like certificate C but isn't.

Now if M does something to man-in-the-middle me, my understanding is that M's server shows me Q, I see Q signed by N, I trust N's root certificate, everything is dandy...except it's not because M can see all my plaintext, and is free to do with it as he wishes, including the other half of the MITM if he wants, passing the information on to B, etc.

(I know this is a classic MITM with an SSL twist, but I just wanted to be really clear with my logic just in case I missed something along the way that's relevant.)

I'm guessing that there's some other protection to mitigate against this, I presume? I hope? ...Please?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Short answer: It is not secure against rogue CAs. But Q can't look exactly like C, it'll have N as root and not A. $\endgroup$
    – CodesInChaos
    Commented Jun 25, 2013 at 7:32
  • $\begingroup$ @CodesInChaos: Well, yeah, but my browser won't know which CA is supposed to be issuing the cert. It'll just check validity, and then merrily pass all my information along. And for practical purposes, I'm not going to read every cert by hand, and in theory if I did, each company would have to list who their CA is somewhere for me to look it up, and I'm pretty sure they don't... Alright, well, that's depressing, I suppose. $\endgroup$
    – King Spook
    Commented Jun 25, 2013 at 10:59
  • $\begingroup$ The browser will check validity against the CA certificates the browser trusts. Do you trust that the browser manufacturer does not include any rouge CAs in that list? Think carefully before you answer. $\endgroup$
    – Henrick Hellström
    Commented Jun 25, 2013 at 11:06
  • $\begingroup$ In basic HTTPS, there is no protection against this attack. And it has been conducted in real life. However, there are a number of proposals to address this attack that have reached various stages of deployment but generally require either the client or the server to opt-in. For a history of these attacks and a list and evaluation of solutions, see this paper: people.scs.carleton.ca/~clark/papers/2013_sp.pdf (In particular, the first 8 rows in Table 1) $\endgroup$
    – PulpSpy
    Commented Jun 26, 2013 at 14:47

2 Answers 2

Reset to default
3
$\begingroup$

SSL offers protection against Man-in-the-Middle only if the client can make sure that what it believes to be the server's public key is, indeed, the true server's public key. X.509 certificates aim at providing this information, but this is relative that no rogue CA was involved. A "rogue CA" is here one of:

  • An evil or gullible root CA ("subverted" CA might be a more neutral term).
  • An evil or gullible intermediate CA, whose own certificate was issued by another CA (going up to a trusted root).

In fact, rogue CA are out of scope of X.509. It is a strange assertion, but its meaning is that X.509 works on damage containment:

  • If a mishap occurs, revocation is used to limit damage in time.
  • Though nothing technically prevents a rogue CA from issuing a fake certificate, it leaves traces; namely, the fake certificate points at the rogue CA for being, indeed, rogue. Fear of retaliation is supposed to keep CA honest and robust.

Even though a basic OS or Web browser tends to trust a hundred root CA or so by default, and that this trust is limited by the weakest of all of them, it so happens that "mishaps" involving a subverted CA are rare, about once a year or so. This means that the system kind of works in practice. Your understanding of the problem is correct, but experience shows that the mitigations which are in place (retaliation from legal/police forces, and revocation and OS/browser patches) make the attack "not worth it" for the attacker (it won't work for long, and it is risky), which explains why such attacks remain infrequent. I daresay that X.509 is not the weakest link in SSL-powered Web site (and SSL is not the weakest link either; the Web site is the usual problem).

Improve this answer
$\endgroup$
1
  • $\begingroup$ Government-affiliated CAs seem to be practically immune to some of that, though. "Oh, you can't sell your X here unless it trusts our root Y." Or simply have bona fide sites that users want to visit also share a root with some state-sponsored shenanigans. $\endgroup$
    – Nick T
    Commented Nov 2, 2016 at 14:13
1
$\begingroup$

The scenario you propose has happened in the past but does not indicate a failure with the SSL, rather a failure in the CAs you have "chosen" to trust.

By definition, you should trust all the CAs in your "Trusted Root Certification Authorities" store to have a good Certification Practice Statement (CPS) and to comply with it. You should be comfortable that they will not issue certificates without doing a certain level of checking that the requester does own the domain for which they are requesting a certificate.

Where a rogue certificate is issued by a CA, the CA is not trustworthy and you were wrong to include it in your trusted store.

In reality, few people choose which Certification Authorities they trust - they accept the CAs which the OS or Browser manufacturer has chosen to include in the store. They trust that Microsoft (or whoever) has done the relevant checks on their behalf.

If you are paranoid, there are various browser plugins which will give a warning if the issuer of a certificate changes between visits to a site.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.