Mailing List Archive: [Bug 2594] CNAME handling can break TLS certificate verification

[Bug 2594] CNAME handling can break TLS certificate verification

Mar 13, 2021, 2:56 AM

Post #1 of 4 (510 views)

https://bugs.exim.org/show_bug.cgi?id=2594

Heiko Schlittermann <hs@schlittermann.de> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |hs@schlittermann.de

--- Comment #11 from Heiko Schlittermann <hs@schlittermann.de> ---
Checked in real-world and it seems to work as expected. The router sets the
host to smtp.office365.com, DNS CNAMES redirect to a bunch of other names which
in turn resolve to addresses.

The certificate the peers present match the hostname of the router and Exim
now can verify that.

Thanks.

--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Re: [Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]

exim-dev at exim

Mar 14, 2021, 6:33 AM

Post #2 of 4 (509 views)

Permalink

For the record, the expectation is:

- Absent DANE TLSA records, the literal MX hostname, which is
of course insecurely obtained from MX records, so validation
is mostly an exercise in futility. It would only mean something
if MTA-STS were implemented, but Exim does not MTA-STS last I
heard.

- If DANE TLSA records are found at some "TLSA base domain"
(which is either the securely CNAME expanded MX host, or else
the original MX host from the signed MX RRset), then that's
the name to use in SNI and check in the certificate when validating
"2 X X" TLSA records).

> On Mar 13, 2021, at 8:56 AM, admin--- via Exim-dev <exim-dev@exim.org> wrote:
>
> Checked in real-world and it seems to work as expected. The router sets the
> host to smtp.office365.com, DNS CNAMES redirect to a bunch of other names which
> in turn resolve to addresses.
>
> The certificate the peers present match the hostname of the router and Exim
> now can verify that.

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Re: [Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]

exim-dev at exim

Mar 15, 2021, 1:24 AM

Post #3 of 4 (506 views)

Permalink

Viktor Dukhovni via Exim-dev <exim-dev@exim.org> (So 14 Mär 2021 14:33:21 CET):
> For the record, the expectation is:
>
> - Absent DANE TLSA records, the literal MX hostname, which is
> of course insecurely obtained from MX records, so validation
> is mostly an exercise in futility. It would only mean something
> if MTA-STS were implemented, but Exim does not MTA-STS last I
> heard.

If the next hop's hostname comes from insecure DNS, you're right. If the
next hop's hostname is hard-wired into the configuration (as typically
found in "use-a-smarthost" setups), I believe, it's useful to check the
next hop's certificate prior sending credentials or other private data.

--
Heiko

Re: [Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]

exim-dev at exim

Mar 15, 2021, 1:45 AM

Post #4 of 4 (506 views)

Permalink

> On Mar 15, 2021, at 6:24 AM, Heiko Schlittermann via Exim-dev <exim-dev@exim.org> wrote:
>
> If the next hop's hostname comes from insecure DNS, you're right. If the
> next hop's hostname is hard-wired into the configuration (as typically
> found in "use-a-smarthost" setups), I believe, it's useful to check the
> next hop's certificate prior sending credentials or other private data.

Yes, in the absence of MX lookups, the nexthop host is securely
known, and can be validated. This is in fact typical for submission,
where MX lookups don't apply.

Thus a locally configured nexthop of [smtp.example.net]:587 can and should
be subject to TLS certificate checks, and not subjected to CNAME expansion,
unless somebody also has DANE for port 587 (and TLSA records on the far end
of an end-to-end signed CNAME chain).

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##

Mailing List Archive

Mailing List Archive

Attached Files: