> David Schwartz wrote:
> >>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.
> > Huh? The MITM could just proxy all the data between two distinct SSL
> > connections and he would know all the data that was supposed to be sent
> > securely. Yes, he couldn't tamper with the data, but that's hardly
> > sufficient.
> To be specific, I was suggesting something like:
>
> 0. Client and server negotiate vanilla SSL handshake sequence, including
> the Finished messages, but do not send any application data yet.
> 1. (a) Client sends HMAC[shared_secret](Finished_C || Finished_S).
> (b) Server verifies this HMAC by obtaining the two Finished messages
> from its end of the SSL session.
> 2. (a) Server sends HMAC[shared_secret](Finished_S || Finished_C).
> (b) Client verifies this HMAC by obtaining the two Finished messages
> from its end of the SSL session.
> 3. Application data starts flowing.
Ahh, I misunderstood you. The only problem is that, AFAICT, OpenSSL
provides no way to extract these messages. So, at a minimum, changes to
OpenSSL would be required. That's not impossible, just unfortunate.
> The Finished messages are cryptographically derived from the premaster
> secret, and the MITM can't control their contents. If an MITM was
> proxying between two distinct SSL sessions, the HMAC computed in 1a
> would not be accepted by the server in 1b, since the Finished_C and
> Finished_S messages would be different. And without the shared_secret,
> the MITM can't compute an HMAC value that would pass the server's check
> in 1b.
>
> Think of it as challenge-response, but with the challenge value
> cryptographically tied to the SSL secret.
That's exactly what I want. I'm not clear on how the shared_secret is
determined. If neither end has complete control over it, this is perfect.
However, I thought the server got to choose it. In this case, the MITM will
know it on one end and get to choose it for the other end and can therefore
make it the same on both ends.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
