> > In this second step of verification, you can exchange public keys, > > certificates, challenges, responses, and so on. Each side can > > verify what it > > is talking to on the other side by whatever mechanism you want.
> Ahh, yes, ok. But the result would not be SSL but > something-SSL-based, right? Well, by this someone could use e.g. > symetric keys for authentication - if it fails the session could > be discarded, right. It would be SSL for everything except the MITM detection. SSL provides the transport encryption. > > Again, the only serious potential gotcha is a MITM who might replace the > > single SSL session with his two (one to each end) and proxy the > > second step > > and then takeover or monitor the data connection. Ensuring that > > each side's > > SSL_get_finished matches the other side's SSL_get_peer_finished > > should be > > sufficient to prevent this. (Include these in the signed objects you > > exchange.) > I'm not sure if I understand "...including these...". If, for > instance, each side (and only them) share a secret 3DES key and > use it for some challenge-response-authentication inside a SSL > tunnel then I would assume that this is secure because it would > be secure without the SSL and thus should be with it. No, because a MITM could interpose his own SSL connection to both sides, proxy the challenge-response authentication and then view or modify the plaintext. If you don't verify the name in the certificate, SSL provides everything you need *except* MITM detection. So you just need to add that. Once you verify that the two programs that are going to exchange secure data have opposite ends of the *same* SSL connection, SSL does everything you need. > beside the > fact, that I don't see the advantages of SSL here. A MITM could > forward this authentication, so based on the challenge-response > some session key needs to be derived to be used as encryption key > (to make the MITM unable to read or change the forwarded data). > Is that right so far (in such a setup, what is the SSL for BTW)? If a MITM forwarded the authentication, the authentication would fail because the authentication objects would not match the 'finished' data. If a MITM interposes his own SSL connections, then the 'finished' data will not match, > So your point is that some property from the original certificate > (lets say some hash or so) could be included in the extra > authentication to detect a MITM (or whatever faked) certificate? > In that case, SSL would be used basically for encryption only, right? Exactly. > Are such schemes used in practice? Or is it more a theoretical > idea showing what would be possible? Yes, they are. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
