Duane wrote:
I think you slightly missed my point, issuing duplicate certificates for the most part would be real would have been requested and wouldn't be as easily detected by bots or humans alike, the browser wouldn't pop up a message and you would have to carefully scrutinise all key fingerprints with originals, and if the original reported by the CA is in fact the duplicate basically no one would have any chance to verify against anything, this goes if it was a commercial CA, or a CA setup by a government for snooping purposes...
Your original point rather lacked details, and to me it's still not clear exactly what kind of attack you are proposing.
Then of course this could lead on to DNS being hijacked and all sorts of messy things, it might get picked up, but I highly doubt it...
What it takes is one person connecting to their own SSL server over the Internet from a point where the DNS was hijacked, checking the cert chain content. Perhaps they only have one particular CA trusted, not the default set for all browsers, and therefore the chain they are seeing isn't trusted . It's not the cert chain that their SSL server actually sends, but a chain of fake certs from an SSL "proxy" server in between . Then all you have to do is look at that cert chain . If it maps to certs that ship as trusted in browsers, it's time to report it and get the root to lose its Webtrust certification, and removed from browsers.
Also, the server administrator could notice all the connections coming from that proxy's IP address in his logs, as opposed to individual clients.
You could however easily make the point that someone concerned about government spoofing however might not be running with the default set of trusted roots that Mozilla chooses, however. Just as people in the military would not trust all the roots Mozilla ships - they probably just remove the root cert module, and use their own roots.
One of the biggest problems with the set of roots we ship today is the lack of name constraints at the root level. In theory, in the PKI model, name constraints are used, so that only one particular CA can issue certs for a given entity subject. This incorrect assumption is made in many RFCs, including the latest RFC3280 . When that is not the case, certain security holes open up, some of which I pointed out on ietf-pkix and are being addressed. But mostly, the overlap problem cannot truly be resolved with the current roots.
To take a real-world example, I can get an e-mail cert from Thawte with my sun.com address . I don't have to get that cert from the sun.com CA . And most e-mail clients will trust that cert for e-mail purposes. In a sense this is good, since there is no sun.com CA for me to get a cert from. But if there was, there would be no way to enforce that the sun.com CA is the only one authorized to sign certs for sun.com e-mail addresses . The name constraints model truly only works if the roots have disjoint name constraints, which they don't today. If there is an intersection of several CAs that you trust to issue the same subject cert, then the problem you described - and many others - can occur. But to fix this would basically eliminate any competition for CA certs .
Imagine if only Verisign could sign .com server certs, and only the French government CA could sign .fr server certs. The prices would skyrocket. Yet, there would be fewer vulnerabilities in that model. The possibility of "duping" a CA, as you put it, would not exist, merely the possibility of the exclusive CA itself being malevolent or incompetent, which is a case that can never be ruled out, but one that can be discovered and dealt with (if in a painful manner).
With all the DNS hijacking that took place last decade and all the countries that exist in the world I'm assuming it wouldn't be difficult at all to dupe a CA, how many would care to verify? After all it only takes one and the whole thing comes crashing down, which is why Ian has been pimping the idea on branding so much, then it's explicitly out in the open as to who issued the certificate. Perhaps he doesn't go far enough, perhaps when the logo is clicked on another window should open up with a brief run down on how that CA issues certificates, then again, very few would read the fine print until after the fact and they're looking to sue someone...
Yes, it only takes one bad root to mess up the system, but it also only takes one person noticing the incorrect operation to prove that the root CA is acting in bad faith, and remove it.
That's why revocation is important, and there has to be a process to revoke malevolent root CAs as well. Unfortunately, the only way to do that is to mark them untrusted, or remove them from the built-in root module. For most people, the later mechanism will work better. There could be a security alert about it, just like for other exploits, and people would get the new browser. Microsoft already distributes updated roots with Windows updates, BTW, and I presume they also delete bad ones (or old ones).
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
