Mailing List Archive

[Bug 2594] CNAME handling can break TLS certificate verification
https://bugs.exim.org/show_bug.cgi?id=2594

Chris Paulson-Ellis <chris@paulson-ellis.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|CNAME handing can break TLS |CNAME handling can break
|certificate verification |TLS certificate
| |verification

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

--- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
Can you locate a standards document specifying the name that should be checked
against the certificate?

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

--- Comment #2 from Chris Paulson-Ellis <chris@paulson-ellis.org> ---
I thought you might ask that :-)

I don't think this specific issue is explicitly addressed in either the SMTP,
TLS or HTTPS RFCs. HTTPS is quite clear that the name being tested comes from
the URI, but doesn't go into specifics.

I'm not surprised by this - the resolution of names to IP addresses belongs to
a different layer - the DNS resolver - and the DNS RFCs talk about how to
obtain an IP address, not about what you might otherwise do with the data
obtained along the way.

However, the current exim behaviour is clearly inconsistent with what web
browsers actually do. If an HTTPS server returns a certificate for the CNAME
rather than the original FQDN in the URI, then the browser will fail the
verification.

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

--- Comment #3 from Jeremy Harris <jgh146exb@wizmail.org> ---
All very well... but an MTA is not a browser.

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

--- Comment #4 from Chris Paulson-Ellis <chris@paulson-ellis.org> ---
The STARTTLS RFC 3207 is not very helpful, describing it as a local matter and
using words like probably:

4.1 Processing After the STARTTLS Command

...

The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:

- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.

--
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 ]
On Mon, Jun 08, 2020 at 12:48:22PM +0000, admin--- via Exim-dev wrote:

> https://bugs.exim.org/show_bug.cgi?id=2594
>
> --- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
> Can you locate a standards document specifying the name that should be checked
> against the certificate?

Yes: https://tools.ietf.org/html/rfc6125#appendix-B.4

The original reported is right. Aside from DANE, the correct name to
check in the certificate is the original name, not the (generally
insecure) CNAME expansion.

With DANE SMTP (RFC7672) CNAMEs can *augment* the set of valid names to
check in the certificate, to include the name associated with the TLSA
base domain, which might be a fully-expanded CNAME, provided the
expansion never strayed into a DNSSEC-unsigned zone.

https://tools.ietf.org/html/rfc7672#section-3.2.2

--
Viktor.

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

Phil Pennock <pdp@exim.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |pdp@exim.org

--- Comment #5 from Phil Pennock <pdp@exim.org> ---
If DNS is DNSSEC-signed and validated, then the DANE specs for email say to
chase CNAMEs to get the validated name, IIRC.

If DNS is not provably signed, then the only input for verification is the
hostname as entered into configs, or into the mail; DNS is then an _untrusted_
resolution mechanism and intermediate results are not appropriate for use as
identities to be validated as present in certificates.

In TLS, the cert hostname to validate should always, barring exceptional
override, be the same as the hostname sent in SNI.

In the original bug-report here:

"""
Cert hostname to check: "mail.edesix.local"
Setting TLS SNI "mail.dev.edesix.com"
"""

That is clearly an unfortunate combination. The first should use the same
value as the second.

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

--- Comment #6 from Chris Paulson-Ellis <chris@paulson-ellis.org> ---
(In reply to Phil Pennock from comment #5)
> In the original bug-report here:
>
> """
> Cert hostname to check: "mail.edesix.local"
> Setting TLS SNI "mail.dev.edesix.com"
> """
>
> That is clearly an unfortunate combination. The first should use the same
> value as the second.

Interesting info about DANE.

For information - the TLS SNI value comes directly from my configuration. I
didn't set it deliberately, but in the default config, smarthost_smtp has
tls_sni = ROUTER_SMARTHOST, the macro also used in the smarthost route_data. So
in my config they are the same.

I accept that my DNS set-up is not all that common in the context of SMTP. Not
least because if it was MX driven, then CNAMEs would not work. It's only
because it's a smart host and therefore a "normal" host name that this issue
arises.

Perhaps the default config smarthost router should have an option making the
CNAME behaviour configurable?

--
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 ]
On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:
> On Mon, Jun 08, 2020 at 12:48:22PM +0000, admin--- via Exim-dev wrote:
>
>> https://bugs.exim.org/show_bug.cgi?id=2594
>>
>> --- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
>> Can you locate a standards document specifying the name that should be checked
>> against the certificate?
>
> Yes: https://tools.ietf.org/html/rfc6125#appendix-B.4

So, actually RFC 3207 - and only "probably". Not even SHOULD.
Ho hum.
--
Cheers,
Jeremy

--
## 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 ]
On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:
> On Mon, Jun 08, 2020 at 12:48:22PM +0000, admin--- via Exim-dev wrote:
>
>> https://bugs.exim.org/show_bug.cgi?id=2594
>>
>> --- Comment #1 from Jeremy Harris <jgh146exb@wizmail.org> ---
>> Can you locate a standards document specifying the name that should be checked
>> against the certificate?
>
> Yes: https://tools.ietf.org/html/rfc6125#appendix-B.4
>
> The original reported is right.

No, it's worse. If you take that RFC 3207 wording strictly:

- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.

it could mean the domain part of the recipient email address,
pre-MX-lookup. Thanks to the word "domain".

Or it could mean that, again, but only when there is no MX record
and an A / AAAA is being used... but pre-CNAME.

Or it could mean post-CNAME, because that "client" SMTP agent surely
thought it was connecting to a name that A/AAAA resolved to the IP for
the connect() syscall.


It really is not well specified.

--
Cheers,
Jeremy

--
## 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 ]
On Tue, Jun 09, 2020 at 04:41:33PM +0100, Jeremy Harris via Exim-dev wrote:

> On 08/06/2020 14:51, Viktor Dukhovni via Exim-dev wrote:

> > Yes: https://tools.ietf.org/html/rfc6125#appendix-B.4
> >
> > The original reported is right.
>
> No, it's worse. If you take that RFC 3207 wording strictly:
>
> - A SMTP client would probably only want to authenticate an SMTP
> server whose server certificate has a domain name that is the
> domain name that the client thought it was connecting to.
>
> it could mean the domain part of the recipient email address,
> pre-MX-lookup. Thanks to the word "domain".
>
> Or it could mean that, again, but only when there is no MX record
> and an A / AAAA is being used... but pre-CNAME.
>
> Or it could mean post-CNAME, because that "client" SMTP agent surely
> thought it was connecting to a name that A/AAAA resolved to the IP for
> the connect() syscall.
>
>
> It really is not well specified.

Perhaps so, but in the context of everything else in RFC6125, and the
specs for other protocols, ... it is fairly clear (to me anyway) that
the intent is to match the SMTP server name prior to CNAME expansion,
just like the HTTP/IMAP/... cases.

This is also, FWIW, what's expected with MTA-STS.

--
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 ]
On 09/06/2020 18:33, Viktor Dukhovni via Exim-dev wrote:
> Perhaps so, but in the context of everything else in RFC6125, and the
> specs for other protocols, ... it is fairly clear (to me anyway) that
> the intent is to match the SMTP server name prior to CNAME expansion,
> just like the HTTP/IMAP/... cases.

Given that HTTP/IMAP don't do MX lookups, the argument-by-analogy
is dubious.
You could as easily use it to justify the first of my three options.

I'm not saying I think you've chosen then wrong thing, only that
the lawyering is weak.
--
Cheers,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED

--- Comment #7 from Jeremy Harris <jgh146exb@wizmail.org> ---
(In reply to Phil Pennock from comment #5)
> In the original bug-report here:
>
> """
> Cert hostname to check: "mail.edesix.local"
> Setting TLS SNI "mail.dev.edesix.com"
> """
>
> That is clearly an unfortunate combination. The first should use the same
> value as the second.

The SNI to be sent derives from a transport option. The writer of the config
has full latitude for foot-shooting. Of course, in the context of this bug we
realise that said writer has precious little help in obtaining a value which
would be in line with the discussions on exim-dev - that the value to be
compared
for certificate name-checking should be the result of any MX lookup, or the
start of any CNAME chain leading to the eventual A or AAAA.

I'll leave that issue for later.

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

Git Commit <git@exim.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |git@exim.org

--- Comment #8 from Git Commit <git@exim.org> ---
Git commit:
https://git.exim.org/exim.git/commitdiff/0851a3bbf4667081d47f5d85b6b3a5cb33cbdba6

commit 0851a3bbf4667081d47f5d85b6b3a5cb33cbdba6
Author: Jeremy Harris <jgh146exb@wizmail.org>
AuthorDate: Thu Jun 11 20:21:38 2020 +0100
Commit: Jeremy Harris <jgh146exb@wizmail.org>
CommitDate: Thu Jun 11 20:30:18 2020 +0100

tls: use rfc 6125 rules for certifucate name checks when cnames are
present. bug 2594
----
doc/doc-docbook/spec.xfpt | 10 ++++--
doc/doc-txt/ChangeLog | 7 +++-
src/src/host.c | 23 ++++++++++--
src/src/structs.h | 19 +++++-----
src/src/tls-gnu.c | 4 +--
src/src/tls-openssl.c | 20 +++++------
test/confs/2012 | 76 ++++++++++++++++++++++++++++++----------
test/confs/2112 | 76 ++++++++++++++++++++++++++++++----------
test/dnszones-src/db.example.com | 5 ++-
test/log/2012 | 34 +++++++++++-------
test/log/2112 | 36 ++++++++++++-------
test/scripts/2000-GnuTLS/2012 | 9 +++--
test/scripts/2100-OpenSSL/2112 | 12 ++++---
13 files changed, 234 insertions(+), 97 deletions(-)

--
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/ ##
[Bug 2594] CNAME handling can break TLS certificate verification [ In reply to ]
https://bugs.exim.org/show_bug.cgi?id=2594

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED

--- Comment #9 from Jeremy Harris <jgh146exb@wizmail.org> ---
Nobody commented

--
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/ ##