marcel wrote:
Another point here will be self-signed certs...
Not sure what you meant by this?
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.
Yup. Although the other defences that have been proposed (branding, etc) will still work. What they effectively do is take us back to when info on the SSL connection was important, and drag the user (perhaps kicking and screaming) back into the security protocol. In this case, the browser can give the user some sense of how well the browser knows the cert - never before? many times?
IMHO browsing security doesnt work without the user involved.
Correct. It's standard security modelling that security is top-to-bottom. The secure browsing model tried to eliminate it from the user level (to a large extent due to a. lots of user pressure and b. the absence of an attacker). Yet, that act weakens its security dramatically.
The question of where to go from here is driven then from the threats. Primarily, the dangers that are being experienced are phishing. As a sideeffect, the other great threat is that the current structure works to deny SSL protection from the vast majority of users/apps. But, as they are not heavily threatened, it's easy to argue that they don't need to be protected. Not an argument I like, because it removes the choice from the user, and assumes that the developer knows best.
> I really
like your suggestion about branding (altough I dont know all the details),
I am in the background writing up the proposal more completely, but the essence of it is this, just quickly:
1. browsers should 'brand' the certificate
and the CA by displaying a branding box
on the chrome. This box should include
a certain amount of fluff in it, such as
images from the CA, as distributed by the
product or as signed by the CA. 2. Cert usage should be cached and analysed.
specifically, when I log into my Bank of
America for the hundredth time, I want to
see a nice pretty 100 in the branding box.
If I get phished to the Funk of Amerika,
I want to see a big bad bold 0 up there
instead. 3. Self-signed certs should be branded as
some bland thing in the branding box, and
no warnings should popup. Self-signed
certs should not be warned against because
the represent an improvement over the
alternate, which is unprotected HTTP.
I.e., we warn when something is wrong,
not when something is better. 4. Webservers should install automatically
in HTTPS mode and bootstrap a self-signed
certificate. This should be designed to
encourage people to do more SSL. If they
can do this, and browsers like it (see 3.)
then later on, successful sites can upgrade
to a CA-signed cert. (this is more an
Apache / IIE issue, not a Mozilla issue.)Those are the 4 key steps.
> the suggestion about a TTP listing trustworthiness of the CAs
is just some addition. Branding leads to a situation where newly started CAs have some "market entry barrier" (in german "markteintrittsbarriere", dont know the exact english word).
That's correct, branding will make TTP listing of CAs as valid. Until Verisign gets a capability to brand itself to users as being "better" then it is invisible, and thus Verisign cannot be better than any other, no matter how many boxes and checks you put in, as far as the user perception goes.
The creation of branding to the user is essential to get the CAs to compete on quality, and thus raise the bar against CA-substitute attacks.
> I'd call
this model "static" (Bruce Schneier), a TTP web site would be more dynamical and under the control of the mozilla foundation (e.g. if a CA isnt trustworthy any more, how does branding handle this? Revocation or OCSP?)
Branding simply tells the user. If the CA isn't trustworthy any more, it will become a bad brand. The user may be more careful with brands that aren't recognised or thought to be dodgy. At the moment, there is no incentive for the CA to keep clean, as even if found out, the user never sees their name.
(The literature I found doesnt really state much about this, mostly its said "do not trust any CA unless you're really sure...";
What literature have you found that seriously addresses the security model? I'm surprised you've found anything addressing the CA, as this is something that is out of the hands of the user.
I wasn't able to find anything serious, and relied on Eric Rescorla's SSL book and a bunch of papers. For the most part, I've collected my information at http://iang.org/ssl/ and http://iang.org/ssl/pki_considered_harmful.html#links
Yes thats what I rely on too. Some other interesting sources are the books and articles from Bruce Schneier, e.g. his "10 risks about PKI" (Http://www.counterpane.com/pki-risks-ft.txt) or cyberworthiness (http://csdl.computer.org/comp/mags/sp/2004/02/j2073abs.htm)
I haven't seen the latter article, but it seems that one has to buy it. I don't understand those publishers.
trying to enhance with the TTP web site; and thats what Microsoft wants to solve with their "root cert update").
CA-signed certs aren't under attack, secure browsing is. So it seems likely that a root cert attack is more of a theoretical issue or a design issue - which might suit your purposes admirable.
Well I also hope this doesnt change... but I'm pretty sure once the importance of SSL (or email certs, e.g. against spam as someone proposed) increases, there will be attacks against it. (The same for software signing.)
Opinions differ on the future of SSL. It's not the golden child it once was. The SSL/CA model now has a track record and other systems are being used. Some people think its use will decrease over time, others think it will increase.
In a sense, one could make the case that there is no point in changing it, as it would be better to start from scratch. I don't argue that, I think as far as browsing goes, we are stuck with what we have, and we are better off tweaking the stuff that is there. Hence the relatively small list of changes proposed above.
(Software signing and CA-signed email I see as applications that haven't really taken off as yet.)
Regardless of that, I'd suggest that you would have to address how the CA-signed cert attacks work alongside with your investigations into how the root cert gets attacked. As in, the two should be treated hand in hand, as addressing one risk without covering the other will leave one exposed, academically.
Thanks for the suggestion! You mean CA-signed certs from an already trusted CA, e.g. with a wrong identity? (like the verisign giving out a cert for a wrong Microsoft employee). Or do you mean hacking the CA? Or what could be done once I've managed to get a faked root installed?
All of the above :) Have a browse through this: http://iang.org/maps/browser_attack_tree.html (you need applets enabled).
iang _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
