Mailing List Archive

On Tue, 29 Aug 2023, Exim Bugzilla via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=3021
>
> Bug ID: 3021
> Summary: patch: The essence of a MITM is not that both I and
> the server still think I have an encrypted connection
> Product: Exim
> Version: 4.96
> Hardware: All
> OS: All
> Status: NEW
> Severity: bug
> Priority: medium
> Component: Documentation
> Assignee: unallocated@exim.org
> Reporter: u34@net9.cf
> CC: exim-dev@lists.exim.org
>
> There is an attempt in parenthesis to shortly clarify what is the problem with
> a MITM. I feel the clarification should be with other words.
>
> diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
> index d0f310f57..d02e309c8 100644

The patch does not clearly show the changed wording (diff is too
interested in the changed line breaks) so here it is re-wrapped
for human consumption:

DNS-based Authentication of Named Entities, as applied to SMTP
over TLS, provides assurance to a client that it is actually
talking to the server it wants to rather than some attacker
operating a Man In The Middle (MITM) operation.
-The latter can terminate the TLS connection you make,
-and make another one to the server (so both you and the server
-still think you have an encrypted connection)
+The latter can terminate the TLS connection you have with the server,
+and make another one (so both you and the server
+wrongly feel the encryption protects against interception)
and, if one of the "well known" set of Certificate Authorities has
been suborned - something which *has* been seen already (2014), a
verifiable certificate (if you're using normal root CAs, eg. the
Mozilla set, as your trust anchors).

The new version suggests that a connection between me and the
intended server starts and then ceases, so I would have to
say this is worse than the original.
If we are going to make a change, the word 'terminate'
is confusingly ambiguous. It is used here to indicate where
one of the end points is, but it read as if an existing
connection ceases.

How about replacing the -+ text with:

(A MITM attack creates a situation where both the client and
the serverhave encrypted connections to the attacker but
believe they are talking directly to each other)

?

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

On Wed, Aug 30, 2023 at 08:54:40AM +0100, Andrew C Aitchison via Exim-dev wrote:

> The patch does not clearly show the changed wording (diff is too
> interested in the changed line breaks) so here it is re-wrapped
> for human consumption:
>
> DNS-based Authentication of Named Entities, as applied to SMTP
> over TLS, provides assurance to a client that it is actually
> talking to the server it wants to rather than some attacker
> operating a Man In The Middle (MITM) operation.
> -The latter can terminate the TLS connection you make,
> -and make another one to the server (so both you and the server
> -still think you have an encrypted connection)
> +The latter can terminate the TLS connection you have with the server,
> +and make another one (so both you and the server
> +wrongly feel the encryption protects against interception)
> and, if one of the "well known" set of Certificate Authorities has
> been suborned - something which *has* been seen already (2014), a
> verifiable certificate (if you're using normal root CAs, eg. the
> Mozilla set, as your trust anchors).
>
> The new version suggests that a connection between me and the intended
> server starts and then ceases, so I would have to
> say this is worse than the original.

I concur that the suggested replacement is likely not an improvement.

> If we are going to make a change, the word 'terminate'
> is confusingly ambiguous. It is used here to indicate where
> one of the end points is, but it read as if an existing
> connection ceases.
>
> How about replacing the -+ text with:
>
> (A MITM attack creates a situation where both the client and
> the serverhave encrypted connections to the attacker but
> believe they are talking directly to each other)

This is noticeably better. It may make sense to first introduce the
concept of MiTM attacks, and then discuss how they're DANE addresses
them.

Without additional counter-measures, SMTP is vulnerable to
Man-in-The-Middle (MiTM) attacks:

- At the DNS layer, by returning forged responses to MX
lookups.

- At the SMTP layer, by modifying the server's EHLO reply
to suppress announcement of STARTTLS. SMTP delivery then
typically continues in the clear, and can be subject to
further interference by the attacker.

- At the TLS layer (in the absence of authentication, or by
presenting a certificate for a forged MX hostname) by
acting as the TLS server for the client's TLS connection,
with the client unaware that it is encrypting a delivery
to (or via) the attacker, rather than the intended
destination.

With DANE, and because DNSSEC is a prerequisite:

- MX lookups are protected from tampering

- TLSA record lookups are protected from modification or rogue
denial of existence.

- In the presence of (usable) TLSA records the client will
use TLS or else will defer the delivery.

- The real MX-host's published TLSA records will need to match
the presented certificate chain, presumably not available to
the MiTM attacker.

In this way, DANE largely prevents MiTM attacks on email delivery
from DANE-enabled SMTP clients to SMTP servers with MX and
associated TLSA records published in DNSSEC zones.

[. One underlying assumption, when DANE-TA(2) ("2 1 1" or
similar) TLSA records are published by the server, is
that is not easy to obtain a forged certificate from the
associated CA. Since DV certificate issuance is also
potentially subject to MiTM attacks, some care is required
to set up sufficiently strict CAA records, ideally require
DNS challenges (protected via DNSSEC), ...

For better security, publish exclusively DANE-EE(3) ("3 1 1" or
similar) TLSA records. ]

Finally, a DANE SMTP server operator who does not implement *monitoring
of the certificate chain vs. published TLSA is not doing themselves or
the SMTP ecosystem a favour. Implement monitoring *before* you deploy
DANE:

https://list.sys4.de/hyperkitty/list/dane-users@list.sys4.de/thread/NKDBQABSTAAWLTHSZKC7P3HALF7VE5QY/

--
Viktor.

--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/