Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
Exim-dev wrote: > If DANE validated the connection attempt then the value of the &%tls_sni%& > option > -is forced to the domain part of the recipient address. > +is forced to the name of the destination host, after any MX- or > CNAME-folowing. Good morning, just saw the patch in git history and stumbled over "folowing". I guess "If DANE validated the connection attempt" should read "If the connection attempt is DANE validated". TIA cu Andreas -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 Jeremy Harris changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 Jeremy Harris changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #13 from Git Commit --- Git commit: https://git.exim.org/exim.git/commitdiff/79aa468aad79f9f1f46efe6a1b2340e7af6fe6f7 commit 79aa468aad79f9f1f46efe6a1b2340e7af6fe6f7 Author: Heiko Schlittermann (HS12-RIPE) AuthorDate: Mon May 3 15:53:28 2021 +0200 Commit: Heiko Schlittermann (HS12-RIPE) CommitDate: Tue May 11 10:49:32 2021 +0200 fix dane + sni handling (bug 2265) broken in d8e99d6047e709b35eabb1395c2046100d1a1dda thanks to jgh and wolfgang breyha for contributions. (cherry picked from commit e8ac8be0a3d56ba0a189fb970c339ac6e84769be) src/src/transports/smtp.c | 4 ++-- test/log/5801 | 28 ++-- test/log/5820 | 4 ++-- test/log/5840 | 6 +++--- 4 files changed, 21 insertions(+), 21 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #12 from Git Commit --- Git commit: https://git.exim.org/exim.git/commitdiff/f093e580a55ad4d41a3ba70bae265b131b5c3bbb commit f093e580a55ad4d41a3ba70bae265b131b5c3bbb Author: Jeremy Harris AuthorDate: Mon Sep 28 22:41:10 2020 +0100 Commit: Jeremy Harris CommitDate: Mon Sep 28 22:41:10 2020 +0100 Docs: Add note regarding DANE vs. the smtp transport multi_domain option. Bug 2265 --- doc/doc-docbook/spec.xfpt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt index b8df139..2e4df80 100644 --- a/doc/doc-docbook/spec.xfpt +++ b/doc/doc-docbook/spec.xfpt @@ -25594,6 +25594,12 @@ It is expanded per-address and can depend on any of &$address_data$&, &$domain_data$&, &$local_part_data$&, &$host$&, &$host_address$& and &$host_port$&. +.new +If the connection is DANE-enabled then this option is ignored; +only messages having the domain used for the DANE TLSA lookup are +sent on the connection. +.wen + .option port smtp string&!! "see below" .cindex "port" "sending TCP/IP" .cindex "TCP/IP" "setting outgoing port" -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 Jeremy Harris changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #11 from Jeremy Harris --- Also see 79b19a30d9, b6054898ac. I think that deals with the functional aspects. There's a logging issue remaining; a cancelled continued-TLS connection is still logged with a continuation marker. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #10 from Git Commit --- Git commit: https://git.exim.org/exim.git/commitdiff/99350dede64ad634300ddf15d0d97a81fd75d330 commit 99350dede64ad634300ddf15d0d97a81fd75d330 Author: Jeremy Harris AuthorDate: Sun Aug 23 15:32:48 2020 +0100 Commit: Jeremy Harris CommitDate: Sun Aug 23 17:05:52 2020 +0100 dane: fix 2-rcpt message, diff domins case. bug 2265 doc/doc-docbook/spec.xfpt| 6 +++ src/src/debug.c | 1 + src/src/deliver.c| 3 ++ src/src/macros.h | 1 + src/src/transports/smtp.c| 71 ++- src/src/verify.c | 2 +- test/confs/5801 | 89 test/dnszones-src/db.test.ex | 1 + test/log/5801| 13 +++ test/scripts/5800-DANE/5801 | 12 ++ 10 files changed, 188 insertions(+), 11 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 Git Commit changed: What|Removed |Added CC||g...@exim.org --- Comment #9 from Git Commit --- Git commit: https://git.exim.org/exim.git/commitdiff/7044dd8fd62e215572ecf5a2c7f1bb9581cf6628 commit 7044dd8fd62e215572ecf5a2c7f1bb9581cf6628 Author: Jeremy Harris AuthorDate: Wed Aug 19 21:09:04 2020 +0100 Commit: Jeremy Harris CommitDate: Thu Aug 20 00:00:22 2020 +0100 dane: force sni to use $domain. bug 2265 note: this is not a complete fix for the issue doc/doc-docbook/spec.xfpt | 14 -- doc/doc-txt/ChangeLog | 13 ++--- src/src/receive.c | 2 +- src/src/smtp_in.c | 2 +- src/src/tls-gnu.c | 2 +- src/src/tls-openssl.c | 1 + src/src/transports/smtp.c | 1 + test/confs/5820 | 3 ++- test/confs/5840 | 3 ++- test/log/2030 | 2 +- test/log/2031 | 4 ++-- test/log/2130 | 2 +- test/log/2131 | 4 ++-- test/log/5820 | 10 +- test/log/5840 | 10 +- test/stderr/5820 | 2 +- test/stderr/5840 | 2 +- 17 files changed, 49 insertions(+), 28 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/ ##
Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
On 17/08/2020 23:33, Viktor Dukhovni via Exim-dev wrote: > The Exim case should be somewhat simpler since nothing is persisted > out of process Not so. -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
> On Aug 17, 2020, at 7:08 PM, admin--- via Exim-dev wrote:
>
> https://bugs.exim.org/show_bug.cgi?id=2265
>
> --- Comment #8 from Jeremy Harris ---
> Disabling multi_domain turns out to be Extremely Painful because we don't find
> out
> that DANE was used until deep in the transport, well after the addresslist was
> built for a message - combined with all the ways Exim tries to re-use a
> connection for multiple messages. I can see it being a fertile source of
> bugs.
FWIW, yes connection and TLS session reuse are tricky in the context of
potentially
different security policies for different destinations. This is a source of
some
non-trivial complexity in the Postfix SMTP client.
The session and connection caches have multi-element lookup keys (run through
SHA256 in the case of the session cache) that combine some of the following
(partial list):
- transport (router) name
- nexthop domain
- TLS security level
- SNI name
- Remote IP address
- Remote name from first line ("250-") of EHLO
- DANE TLSA RRset
- TLS reference identifiers (names to check in the cert)
- ...
This took quite time and effort to build, and there are dedicated
functions for constructing the lookup keys for saving and retrieving
live connections and cached TLS sessions.
The Exim case should be somewhat simpler since nothing is persisted
out of process, but also trickier, because you're trying to collect
multiple messages to send down the connection in real time, rather
than squirreling away the connection for potential reuse by another
separate delivery.
I don't know anything about the internals of multi-domain support
in Exim, but can see that this could be a pain. And yet, it is
largely an unavoidable issue. The security constraints do mean
that some messages that would otherwise be grouped for transmission
over a single channel, can no longer be correctly grouped that way.
--
Viktor.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim
details at http://www.exim.org/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #8 from Jeremy Harris --- Disabling multi_domain turns out to be Extremely Painful because we don't find out that DANE was used until deep in the transport, well after the addresslist was built for a message - combined with all the ways Exim tries to re-use a connection for multiple messages. I can see it being a fertile source of bugs. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #7 from Jeremy Harris --- Seems plausible; all we need is for someone to put in the coding and testing effort. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265
--- Comment #6 from Phil Pennock ---
Viktor notes on exim-users:
---
Thanks for bringing this up. Indeed for DANE it is essential to ignore
any statically configured value and use the "TLSA base domain".
Otherwise, the cert chain you get may well not be the one promised in
the TLSA records.
Postfix ignores the static SNI setting, when doing DANE. Exim needs
to do the same. The required SNI name is specified in RFC7672 (and/or
RFC7671), and should not be second-guessed.
---
... in response to my saying we should probably just ignore the static SNI
setting for DANE.
I also think that we should ignore `multi_domain` and force it false for DANE,
in this case. These days it's expanded, and it always defaults true.
Any objections to:
1. use the DANE-specified hostname variant as the SNI for DANE, when DANE is in
play, ignoring `tls_sni` which then becomes the fallback for non-DANE, same as
{hosts_require_tls, tls_verify_hosts, tls_try_verify_hosts,
tls_verify_certificates, tls_crl, tls_verify_cert_hostnames}
2. Disabling `multi_domain` when DANE is in play.
Really, I'm taking it as a good sign, how much manual configuration disappears
because the MTA can just do "the right thing" with DANE.
--
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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #5 from Jeremy Harris --- You're right about $tls_out_dane not being set early enough, and I do see the simplicity point. It does see a shame to lose the flexibility of being able to set an SNI to something nonstandard though. As a usable variable, it's a shame $tls_out_tlsa_usage isn't _quite_ set early enough... We do have $lookup_host_dnssec but that will cover more than DANE usage. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #4 from Phil Pennock --- (Patch is reversed.) The issue I see is that we don't switch transports based upon DANE or not, or have a way to skip a router if DANE fails (since that's something for later, at SMTP time, when checking hosts). So there's no (sane?) way to have a config which has tls_sni set to something based on "possible expansion lookup" and still have the option be unset for the DANE scenario. I see two approaches here: 1. a. Allow for forced-fail expansion and empty expansion, to mean defaults too b. Add a new expansion variable, $dane_active or somesuch (since $tls_out_dane is set much later, I think?) 2. Say "DANE always uses the SNI set per DANE specs" and force-override, always. IMO 2 is simpler and easier. (Sorry that I haven't gotten to this myself) My assumption is that people who care about SMTP security will have manual overrides for a bunch of domains, as I do, but want DANE to provide automatic improved security when available. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 Jeremy Harris changed: What|Removed |Added CC||jgh146...@wizmail.org --- Comment #3 from Jeremy Harris --- Created attachment 1083 --> https://bugs.exim.org/attachment.cgi?id=1083&action=edit proposed patch -- 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: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
> On Apr 17, 2018, at 4:37 PM, admin--- via Exim-dev wrote: > > SNI for a DANE-advertising site has to be different than one that does not? > Sheesh. Does that not implicitly require that _all_ clients be DANE-aware, > or that _all_ DANE-advertising hosts be prepared to be hit with SNI from > non-DANE-aware clients (and still do the right thing)? > > I think SNI just became useless. A host with TLSA records should expect DANE clients to send the MX hostname as the SNI name. Other clients might use other SNI names or none at all. I don't see how SNI becomes useless. If you've got a matching cert, send that, if not send a default cert. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #2 from Phil Pennock --- DANE requires that SNI point to the MX hostname, to make it easier to manage mass-hosting. This is a good stance but requires DNSSEC to be safe. The hostname to be verified in a certificate should be the hostname from SNI and without DNSSEC, that would mean verifying a potentially-tampered-with hostname. The name to be verified must always have a trustworthy path back to user input. We _could_ auto-switch to MX for DNSSEC, not just for DANE, but that adds more scenarios and IMO it's better to reduce to "DANE vs non-DANE". Thus for the non-DANE case we should stick to $domain by default, if picking a default, else something from per-site configuration of OOB configuration for some domains. That's being addressed in 2266. In a world pre-DANE, SNI is pointless because there's no certificate verification performed. If you're not going to verify, why set a name to select a certificate? It's only because TLS 1.3 _mandates_ SNI if not explicitly countered in an application profile, and I can't be bothered to spend three years fighting under-informed people to push through an application profile for SMTP MX delivery matching reality rather than idealism, that I'm shrugging and picking "something" for SNI in 2266. For submissions/submission+starttls the use of SNI for key/certificate selection makes a lot of sense. For a DANE world it could make sense in the future. -- 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/ ##
[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients
https://bugs.exim.org/show_bug.cgi?id=2265 --- Comment #1 from Jeremy Harris --- SNI for a DANE-advertising site has to be different than one that does not? Sheesh. Does that not implicitly require that _all_ clients be DANE-aware, or that _all_ DANE-advertising hosts be prepared to be hit with SNI from non-DANE-aware clients (and still do the right thing)? I think SNI just became useless. -- 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/ ##
