On 070204 at 16:00, Ben Bucksch wrote: > In private discussion, Eddy of StartCom suggested SSL CA certs for > > * internal sites (company webmail/IMAP, VPN etc.) > * private discussion (blogs, forums, chat) > * generally everything where you supply a login/password. > > I think other solutions are more appropriate in each case. > > Generally, SSL has a root weakness: Certs expire and can be replaced > with new ones silently. This means *any* root CA (e.g. VeriSign) can > issue a cert and hand it to a TLA and my communication partners will not > notice anything. This weakness exists until certs are everlasting > (breaking the current revenue model of CAs) and clients (browsers etc.) > store certificates that they have seen, similar to SSH. I.e. PKI would > be used only for the *first* contact.
That is why I think a browser should do this. One should in general be notified when the current certificate fingerprint does not match what has been seen before on this site, independent from who signed it. Maybe with a side note on the expire-date of the last-seen cert. Add some heuristics to help the end user judge the security level. Currently, there is near to nothing. I tried to implement this as a FF extension but it seems one can not access the SSL-properties of a connection via the extension-interface.. > This problem means that SSL is only appropriate for normal business, > where governments and CAs are not enemies, but is not suitable for > private communication and highly sensitive data. I disagree. If you are in a large corp it may make sense to have your own CA, independent from some 'real' CAs. What tPKI gives you is scaleability, but you need to invest trust(which is bad). > Private communication: Problem as described above. Initial contact > can gain from PKI, but only where realname is important. Given that > most people use nicknames, and it works just fine, not even that > really matters. The only thing that is important is that the "Fred" I > know is always the *same* Fred. Self-signed certs (SSH model) achieve > that. SSL does *not* guarantee that. Whether Fred is actually "Joe" > in real life makes no difference to me. > > Internal sites: I think these should use self-signed certs, and > *reject* CA-signed ones. This is possible, because a physical, thus > secure out-of-band, communication is possible. I think CAs are > actually the weak link here, because they are an external party. They are not if the CA is run by your company. Especially if you can tell the browser to accept this CA for *.you-company.com only. But indeed, a lot of 'cheap' CAs came up and even if you trust e.g. cacert to carefully check what they sign and take good care of the secret key, there is always some risk left. In these cases, the browser will not notify you in any way, which makes this particulary dangerous. > Login: Use HTTP Digest (although nobody uses it :-( ). That's vulnerable > to MITM, though, right? Is there a way to avoid it? I don't see one. You can not avoid MITM without *some* common secret(or one known asymetric secret per peer). Once you have something, you can build up on that. E.g. put the common bits into the exponent of a DH exchange. This is something I find very promising. People are often doing client-authentication inside SSL, be it banking or some forum. This is a common secret that, once established, can really make a difference. As Mozilla/Firefox is not using OpenSSL or GNUtls, I'm currently trying to implement this in NSS as part of my studies. AFAIK, there are currently SOKE and SRP-TLS out there. SRP-TLS is more complicated, but a little more secure in that the server does not need the cleartext password. Maybe someone can comment on that? (great/useless/...) /Steffen _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
