Ian Grigg wrote:
Thanks for your interesting answer, Ian. [...]
In strategic senses it all seems to come down to: use the CA model, as it is, trust the keys, and don't rely on revocation or online checking. If you find you need online checking or revocation, that may be a sign that the CA model doesn't work for your app.
I'm right with you here, sure.
My key argument is a bit different: What happens if a user encounters a spoofed web site wanting him to install a new (rogue) CA root cert? If the user clicks yes, the rogue CA has won (and isnt likely to be de-trusted by this user once again).
Therefore it would be nice to give the user some informations about the CA that asks to be trusted - as this is the moment this kind of attack can be prevented.
Thats why I propose some trusted third party web site including just the informations about the different CA's, listing also the known rogue ones, and the ones that are newer then the users browser version.
Why? - Today when a web site (e.g. a spoofed version of your online bank) presents a rogue cert, you're asked if you trust that. I believe most users just click yes: They dont know enough to decide on their own, so they're up to the informations they get - from the web site asking to install the cert!
Right. That breaches the CA model, and according to the above analysis (which I just scratched down very quickly) you are now onto the path of bandaids and string, so don't expect too much.
Luckily, the notion that an attacker would present a rogue cert is rather unlikely. Currently, pretty much most of the phishing that goes on is without a cert / without SSL. And, yes the user just clicks through. I have seen one phishing case that used an SSL cert, and after investigation, it was clear that the user would continue to click through.
(This will keep happening until the browser security model starts to engage the user in the SSL process, and relates the differences to the user between a trusted session with a bank versus an untrusted session with something that looks like the bank. A bit like the thunderbird notion of spam filtering.)
Right. One of the "signs" that a web site is spoofed _could be_ its SSL certificate, altough today almost no users look at the SSL icon.
But if a rogue CA manages to get its root cert into the trusted cert store, this SSL lock wouldn't be trustworthy any more.
In this view, MS's solution is like consulting a trusted third party (MS), and I think thats what the user needs in such a situation to decide accurately.
That's what I mean by bandaids and string. That's a can of worms.
In my opinion, a link inside the "do you want to trust this certificate?"-dialogue to a mozilla web site listing the different CA's and their status of trustworthiness would be a nice feature.
What do you think about this?
See above, CA1 != CA2 isn't part of the model.
Right, as long as CA1 and CA2 aren't rogue (=not trustworthy at all):)
(The literature I found doesnt really state much about this, mostly its said "do not trust any CA unless you're really sure..."; thats what I'm trying to enhance with the TTP web site; and thats what Microsoft wants to solve with their "root cert update").
/marcel
btw, I'm speaking for myself only; doing my diploma thesis on these kind of things (rogue CA).
Nice topic. I've recently (from talking to people on this group) come to realise that this is a key weakness (CA1 != CA2) within the CA model, but the observation has been floating around for some time.
iang
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
