[EMAIL PROTECTED] wrote:
What instead people *are* saying is that CAs aren't the only way to do security, and that SSH offers a successful example of another way. What is being proposed is not less CA certs, but more CA certs.
Yes, infinitely more. Everyone gets to be a CA. Opportunism!
Every web site and email would be saying "Trust me! Trust me!" Users would have no idea what or whom to trust. Let's not go there again.
Well, actually, let me adjust that: more CAs, and existing large commercial CAs will sell more CAs to a wider market. Read my rant of a few weeks ago.
However, users would have much more idea as to who to trust. Right now, they only have this binary idea, which is ludicrously bad: some cryptographer said that some developer said that some piece of code said that some cert said that some CA said that .... and this site is trusted because there is a green lock that I always ignored.
Yeah, we can improve on that a bit. We can move users on from where they are now.
I had a conversation today with a long-time open source developer about the proposals to change mozilla to use an "SSH model" for security. His eyes got very big in disbelief! I said "yes, people are proposing to read cert fingerprints over the phone to authenticate public keys." He burst out laughing!
Well, I'd encourage this long term guy to join and debate. BTW, I'm not sure that anyone is suggesting that cert fingerprints had to be read over the phone to authenticate public keys.
Also, what do you care? If this idea is dumb, then surely this will encourage merchants of distinction to use a CA-signed cert? Isn't that a good thing?
He said "That's the theoretical SSH model! Let me tell you about the REAL SSH model". He went on to say that people visit an SSH server, it presents an RSA public key, and they just blindly trust it without any effort to check its authenticity first, because that's too inconventient.
Right. It works. The fact that it doesn't follow the no-risk model is the one thing that has contributed to its success, over, for example, Secure-telnet, now just a bad dream, as far as most sysadms are concerned.
Now it's ok to disparage either, but all you are really doing is revealing that you don't agree with the risk equation that system administrators make for themselves, for their networks, and over the open Internet, with their money and their bosses and their bosses customers.
I.e., you are saying that you know better than the sysadms, and web site operators. So much so that you think that they have to spend money because their notion of security is too poor to be trusted.
[Ben B answered your other point.]
(*God help* any political dissidents who fall for that! The human tendency to skip over technical details that are not well understood is *exactly* the reason why non-Uber-Geeks should not use SSH!
God helps any who help themselves. Mozilla's mission is not to save political dissidents on exactly the same terms as they would save grandma's credit card. They are different and incompatible missions. If you confuse them, you will fail in one or the other of the missions (right now, it's the dissident who dies, and grandma doesn't get robbed).
Real security involves knowing your threat model and creating a security model to cover a set of the threats that you are comfortable with.
In this case, the security model for the CA certs system in SSL / browsing, etc, does not cover dissidents who need their lives protecting. If are unsure of this, go ask Verisign. Or, ask QuoVadis or CACert guys, here on this list, to confirm whether they cover lives of dissidents or not.
A cert and public key should mean "you (the party relying on this cert) have MORE assurance of the authenticity of the source (or destination) of this connection (for SSL) or message (for SMIME) than you would have if you didn't use cryptographic security." If a cert/key doesn't better assure authenticity, then it is a sham, giving the (naive) user false security, baseless peace of mind.
No, not really. There are two considerations, encryption and authentication. (Also, integrity, but we can ignore that.) Encryption provides a measure of protection, with one weakness (MITM). Authenticated encryption avoids that weakness, either self-signed with SOME assurance, or, CA with MORE assurance, but at a cost. It's horses for courses.
That isn't a sham, unless you are trying to market certs to all and sundry.
Now, if you believe authentication is not needed for adequate security, if you believe we really don't need more authentication than what we get with present insecure protocols, then why not just drop encryption alltogether?
That is to confuse encryption with authentication, they do not necessarily walk hand in hand. The tying together of these was one of the characteristics of the crypto theory in the nineties, and a thing that has haunted us for some time. Still, the protocol is in place, so we'd best use it as best we can. What people propose is keeping the entire protocol in place, because it's hard to change the crypto, and instead, just use what's there in better ways.
...
This is why I keep my ear to the ground for any data about MITMs. There is very little. There is the one story I heard on this group, relating to a credit card on a student campus, and then there a few stories from other protocol areas (one email story, and one other, can't recall right now).
This allows me to claim - honestly - that MITM is
not the threat that you think it is. I can't prove
it because there is an absence of information.
Obviously, people who have successfully implemented MITM attacks do not find it in their own best interest to reveal what they've done. Victims may also wish to keep quiet. So, the information about MITM attacks is not very public.
Um, you'd maybe hope that, but no, that's not how it works. People who have successfully implemented MITM realise that it is riskier than the alternates. And, those attacks we see working cause reports to be filed in. Eventually a pattern emerges as to attacks, and statistics on the form and success start to build up. There are no statistics on MITM, ergo (and we have a fair degree of confidence in this) it isn't happening to any great extent, such that it's worthwhile worrying about it.
This is standard "insurance industry" style logic. For example, you probably can't get standard insurance against MITM because there is no way to calculate the premium - as there is no body of statistics available. Standard insurance process. Mind you, you would be able to pick up snake oil insurance against MITM.
If someone could show you a massive on-going MITM attack on http and https, affecting thousands of users, how would that influence your position? Please do answer that.
I will - if you address my answer!
Your scenario will allow us to calculate how the risk of MITM effects our decisions. So, taking your numbers without question, if there are thousands of users being hit by MITM, and there are, say $200 of losses every time they are hit, let's call that 200 x 5000 per year, then we get total losses of $1 million.
Now, if the total cost of protecting these people is CA signed certs for all merchants, the current situation, then we look at that cost and compare.
( We can *NOW* look at that number: http://www.securityspace.com/ http://www.securityspace.com/s_survey/sdata/200403/certca.html )
There are 43,430 valid certs out there. Assume an approximate cost (including time) of $1000 per cert. Cost to protect against the MITM: 43 million dollars.
So, I conclude, using your numbers, that it is not worth it.
What does this mean? Not disabling certs, or stopping SSL or ditching the CAs. It implies that the decision to force all merchants to adopt certificates is wrong, costly, wasteful, bone headed, and should be dropped. That is, forcing them to adopt certificates costs them more money than it saves.
The HTTPS policy has created a "tax" or "transfer" that delivers practically no productive benefit to the merchants, at some annual cost.
Now, all this means is: don't force them to use CA- signed certs. Let them start with self-signed (and more CA-signed certs will result). Let them choose, because they know more about their risks, and all risks, than you do.
Phishing is addressed by the sort of measures we have proposed,
Everyone calls their bank (or ebay, or amazon) and asks for the fingerprint of their self-signed cert?
No, I'm sorry that you've picked up this FUD from somewhere. Here's how it is:
Those merchants that want to use CA-signed certs, should do so. Those servers that feel that the self-signed cert is adequate to their needs, should do so. Those users that find a self-signed cert to be insufficient, should choose another provider. Those that don't care, don't use SSL.
In practice, nobody's going to do much in the way of phoning to get the fingerprint, that doesn't make any sort of economic sense. The fact that the SSL self-signed cert *can* be authenticated via finger- print and phone is more of an "entry-level" technique for a startup business, or for a club or association that simply doesn't want to generate additional costs for no real benefit, or a test website or any number of want-to ideas.
The only thing I recall that *might* help is the idea that the browser display more info from the cert to the user. This doesn't help if the user is trusting certs from an untrustworthy source. An MITM attacker will copy the entire subject name from the legitimate server's cert, and could just as easily copy the issuer name also (with some tiny modification, such as a seemingly harmless addition).
Of course it helps. It alerts the user to the fact that it is a self-signed cert, and allows them to decide how trustworthy that cert is! I'm sure the UI people will be able to pick a suitably bland colour to show their displeasure...
It is also how the merchant shows that it is caring about security - bigger merchants will choose a branded CA cert. (BTW, as far as I know, all CAs are unified in wanting this branding capability.)
The other thing that should be added is that the browser should cache *all* certs. This is needed for the phishing protection (which breaches the CA signed cert protection), and also helps to protect the self-signed cert protection.
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
