[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Tue Aug 19 13:49:19 CDT 2008

On Tue, Aug 19, 2008 at 11:44 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
> "Eric Rescorla" wrote:
>> What Dave is suggesting, I think, would be a garden variety TLS handshake with
>> whatever ciphersuites you already support and self-signed certs. Then you'd run
>> SASL with some challenge/response protocol and channel bindings (you'd
>> almost certainly want mutual auth here) and then on the basis of the C/R
>> note that you trusted the peer's self-signed cert.
> That does no work, SASL is not man-in-the-middle-proof:
> user 1 <--> man-in-the-middle <--> user 2
> Now both the keys they do not know. But they are from the attacker. If
> they use SASL on that link they only know that somewhere in the line
> is the user user, they do not know that they talk direct. In this
> scenario you would store the man-in-the-middle keys as verified.
> One idea: user 1 sends a challenge to user 2. The min-in-the-middle
> can see it. Now user 2 generates an answer with password, his public
> key and the challenge. Now it generates the md5 sum and sends it
> back. user 1 does the same. A min-in-the-middle can not create a valid
> md5 because he is missing the password, if there is a
> man-in-the-middle user 2 would use a different public key than user 1.
> This could work.

What David is suggesting is what's called a "channel binding". Basically,
the SASL C/R is tied to the TLS handshake in a way that prevents this
MITM attack.


More information about the Security mailing list