On Tue, Jul 29, 2014 at 11:59:41PM +0200, Patrick Ben Koetter wrote:
> > network path can change any of the three inputs (client IP, client
> > name or client HELO name), so unless the client is using an MiTM
> > resistant sending policy, we can't prevent MiTM attacks, rather
> > we can only detect their absense in some cases and perhaps grant
> > the client greater access.
>
> Correct me if I am wrong: Client-side DANE and/or ccert fingerprint matching
> would be apt to prevent MiTM attacks.
No, it would at best detect their absence when there is no MiTM
attack. Otherwise, when the client is not holding up its side of
the bargain, and not authenticating the server in an MiTM-resistant
manner, there is nothing the server can do to avoid MiTM, because
the MiTM attacker can mask the client's identity.
So unless the client's real identity gets non-default access, all
you get is an audit trail of the success cases, which you believe
were not MiTMed, and the remaining cases may or may not have been.
If the client's identity is used for access control, then potentially
you get more robust access checks via the client's reference identity
(HELO name), when that identity is verified via DANE or PKIX.
You can't get MiTM protection because the client's reference identity
is not known in advance at the server, and can be changed by the
MiTM provided the alternate reference identity gets acceptable
service.
In your logs you might wonder why some mail from a particular domain
is coming from a different IP address or from an unusual HELO name,
but there is nothing on the wire to prove MiTM, all you see is a
connection from a client not subject to the certificate requirements.
I am not saying that evidence of lack of MiTM for some connections
is not useful, but you need to understand the limits of the
technology.
--
Viktor.
