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]

Reply via email to