> Sorry David, but your definition of MITM is wrong. Or, more accurately,
> it is not aligned with how cryptographers and security analysts
> generally conceive it.
I don't see how. I just went to 35 sites that defined MITM and all of them
defined them the way I did.
> In an MITM attack, the adversary sits between A and B and is able to
> intercept and/or modify the communications between the two of them
> without their knowledge.
Right. That is, they don't automatically know he's there. They might be
able to detected he's there from the data, but they aren't provided some
out-of-band "there's a MITM there" signal. (Otherwise no protocol would be
vulnerable to MITM, just don't send anything if there's a MITM.)
If you can determine there's a MITM before you've send any sensitive data,
the MITM attack fails. If the MITM can obtain some plaintext before you
could detect him, he wins.
> Server certificates and "the DN's CN must be
> the FQDN" (sic:) help prevent MITM. (No, it doesn't happen
> automatically -- you have to check the trust chain, certificate keyUsage
> and nameConstraints, and all that other stuff -- but it is possible to
> write code that prevents MITM.)
Exactly. SSL itself doesn't protect you against a MITM attack though it
provides you with all the tools to provide such protection. Just knowing
that a product uses SSL, you would have no way to know whether it was
vulnerable to a MITM attack or not.
I still don't understand where you're disagreeing with me. My definition of
a MITM seems to be the same as yours. A MITM is an attacker who has complete
control over the network between the client and server, unbeknownst to
either of us. A successful MITM attack is one in which a MITM obtains access
to some of the plaintext. (This is slightly simplified.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
