David,
How about having each side send something like HMAC[shared_secret](Finished messages)? I used something similar to this with good results in the SRP Telnet specification. An MITM will cause the Finished messages to be different, and since he won't know the shared secret, he can't "rewrite" the HMAC to match the altered Finished messages. This works with any ciphersuite, including ADH. Just make sure the two sides send slightly different HMACs, e.g. swap the order of client and server Finished messages.
Tom
David Schwartz wrote:
On Sun, May 16, 2004, David Schwartz wrote:
Is there any SSL function to retrieve the other side's public key? I see SSL_get_peer_certificate, but no way to get the public key.
From the certificate call X509_get_pubkey(cert).
My thanks to both of you. It occured to me after I sent my question, though, that I probably should have mentioned what I'm trying to do in case there's a better way to get the effect I need.
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).
However, this assumes that each side has a public key that's used to build the session. I presume that's not really true typically. Would it be sufficient to just have the receiver validate the sender's public key using the shared secret? Or would it be better to exchange validation of the shared secret used in the symmetric cipher?
I suppose SSL's MITM defense should be adequate for my purposes. This is simply to ensure that the server's public key is correct. I presume getting the certificate on the client end (by client, I mean the side that initiated the connection) and extracting the public key will always work.
DS
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
-- Tom Wu Chief Security Architect Arcot Systems (408) 969-6124
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
