> 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. Server certificates and "the DN's CN must be > the FQDN" (sic:) help prevent MITM.
Yes, they help. They do a damned good job of it too.
There are, of course, different ways you could do it -- you could have
a copy of the peer's cert that you get from the remote party in a trusted
manner (CEO brings you the key on a floppy, sent in a PGP signed email
from a PGP key you already authenticated) and then not bother with the
valid CA sig plus CN match, for example.
But without *something*, the game is lost.
> (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.)
You made my point. It doesn't happen automatically. Thus someone
saying that SSL/TLS is immune to MITM attacks is lying.
SSL/TLS plus good authentication methods is immune to MITM attacks.[1]
[1] Depending on everyone you trust being trustworthy. What if I'm
a verisign employee and can manage to generate a verisign-signed
cert for www.microsoft.com? I can MITM, and no alerts will occur
until/unless they figure out what happened and revoke my
certificate, which requires that CRL checking is available in
the client application you're using.
--
Brian Hatch "Are you not the littlest
Systems and bit pleased to see me?"
Security Engineer "Oh my dear, perhaps even
http://www.ifokr.org/bri/ less than that."
Every message PGP signed
pgp00000.pgp
Description: PGP signature
