(Folks, please start new threads. The threads we've been using for the last few weeks have gotten so deep that mozilla can no longer show the tree/hierarchy of messages/replies. So, please, let's use new threads for new topics.)
In a recent post, someone here attempted to defend the practice of using insecure email as the sole means of confirming the legitimacy of a request for an SSL server certificate. I'm here to challenge that. I think it's SO BAD a practice, in fact, that I think mozilla should specifically say, in the policy, that that's not good enough for a CA that is admitted to mozilla's trusted root list. I am not targetting any particular CA here. I think this is a matter of policy for all CAs.
David Stutzman wrote:
> For them to issue you an SSL cert you have to add the domain to your > account. When you want to add a domain you put in the domain name > (example.com) and then it offers you a choice of verification addresses of: > > [EMAIL PROTECTED] > hostmasterexample.com > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > which it then sends an email to the chosen address. In the browser it > says: > > The domain 'example.com' has been added to the system, however before > any certificates for this can be issued you need to open the link in a > browser that has been sent to your email address.
[snip]
> This means I can't start getting amazon.com ssl certs unless I have > control over one of the administrative email boxes of amazon.com and if > *that* is the case then either I work for Amazon and this is valid or > Amazon has other things to worry about than rogue sites such as their > email system's security.
Just over a year ago, someone published an article in a quarterly journal exposing just how easy it is to hijack the email for a domain. Read a draft of it at http://files.juraj.bednar.sk/CA
In his article, he documented a case in point, where he did it, and *succesfully got an SSL server cert for a domain that he did not own,* from a CA that was using email as the only means of verification for SSL server certs.
He explained several ways that he could have done it, and detailed the one means by which he did it. (He had gotten permission from the domain's rightful owner first, but had not used that permission in accomplishing anything that he did. He could have done it all without permission. He explained all this in his article.)
There are many more domains and web servers than there are bad guys, so the bad guys don't have time to attack them all. The bad guys mostly go after the big value targets first. So, lots of people whose email accounts are low value targets can get by without using any security measures whatsoever, because they aren't under attack. And they can point (perhaps in large numbers) to the security (absence of attack, successful or not) they have enjoyed without any measures whatsoever.
But SSL, with its "128 bit" crypto, is about resistance from attack by determined attackers, including people with the computational resources to break a mere 40-bit key. People who go to the bother to deploy such strong resistance to attack are often high value targets, but high value or not, they want to succesfully resist attacks of that magnitude and *ALL easier attacks*.
It has been demonstrated that an attack on an email domain is orders of magnitude easier than attacks on SSL. So, if an attacker wanted to attack a high value target, he would surely attack the email channels before attempting to attack the crypto.
The point is that all that "128-bit crypto" isn't worth a penny if the attacker can get a falsified cert by a simple email channel attack. Giving out strong SSL server certs on the basis of authentication no stronger than insecure email is like building a vault on a foundation of straw. It may be ok for vaults that contain no more than straw, but isn't ok for the rest.
And if browser users ("relying parties") cannot tell the difference
between certs from CAs that base their authentication on no more
than insecure email, woe be to them!So, If I was a CA trying to be admitted to (or stay in) mozilla's list of trusted CAs, I wouldn't brag about, or attempt to defend, my issuance of SSL server certs based on mere untrusted email for authentication.
-- Nelson B _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
