On Thu, Oct 8, 2009 at 1:30 PM, Daniel Veditz <dved...@mozilla.com> wrote: > > Needless to say what you're proposing can't be called "SSL" anymore and > there are sound security reasons SSL does not work that way. Using such a > client to connect to commercial, financial, or government sites would be > profoundly dangerous.
The first sentence of this statement is completely incorrect. The second sentence of this statement is only correct to the extent that an unauthenticated connection does not perform a renegotiation with a provided certificate. (There are some extremely good reasons to allow this situation, and every session that includes a DHE component performs essentially the same thing without hiding the contents of the certificate from non-active attackers -- which might be necessary in certain circumstances and policies.) SSLv2, SSLv3, and all versions of TLS have allowed for a non-authenticated mode. The only restriction is that a server which does not provide a certificate is not allowed to ask the client to provide a certificate. (This is a policy requirement encoded into the standard. I believe that the community would be better served if the language should be removed, especially as other protocols -- like the ipsec suite -- do not require the server to identify itself until it receives a request with a valid certificate.) As well, it is entirely possible to authenticate someone using other-than-cryptographic means across any SSL/TLS connection that does not use certificate-based authentication. (Look at http://zfoneproject.com/ for one example of this, and http://cypherpunks.ca/otr/ for another.) Various proposals for extension of TLS to allow one-time passwords and such (as a means of a pre-shared authenticator) have been made, and all suffer from various flaws. The only thing that all servers can currently support is an unauthenticated handshake, followed by a renegotiation where it actually authenticates. (Even SSLv2 servers could do this, but that protocol's obsolete for very good security-related reasons.) -Kyle H -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
