On Mon, May 17, 2004, David Schwartz wrote: > > > > The situation I have is that I have two entities that have a shared secret > and each has an end of an SSL connection. I need to verify that the two ends > are ends of the *same* SSL connection. (In other words, prove that there is > no MITM.) > > What I was going to do was exchange challenges over the SSL connection, > then have each side encrypt the public key they thing the other side is > using and the challenge with the shared secret. They then exchange these > encrypted blocks. > > My logic is that a MITM proxying data across two SSL connections would have > to replace both 'other side's public keys' with his own public keys. Since > he doesn't know the shared secret, he cannot provide the correct encrypted > blocks. If he provides the wrong encrypted blocks, the connection will be > rejected. If he provides the correct encrypted blocks, then he can't > understand or tamper with any of the data he's MITMing (since he doesn't > know either side's public key). >
Replacing the other sides public keys is prevented by correctly verifying the certificate chains of each side, so additional MITM proection is normally unnecessary. The exception to this is the few unauthenticated cipher suites such as anonymous DH which don't use certificates but those are disabled by default. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
