On Sun, Jul 07, 2024 at 06:34:21PM +0200, Wolfgang via Exim-users wrote:
>
> > Actual debug output from the Exim system. I pointed out how best
> > to do that on the 2nd (assuming that the Exim system is the
> > accepting end for the connection).
>
> > [ In case it's an outbound connection at issue, a simple way to get
> > debug is:
> > exim -d+all -odf fred@??? </dev/null 2>&1 | tee debuglog
> [...]
>
> > ]
In your debug traces, I see no evidece that DANE TLSA records were
obtained or used to establish DANE as the authentication mechanism for
the connection.
Perhaps the issue is as mundane as you not having a local validating
resolver in /etc/resolv.conf, so that the destination domain looks
unsigned to Exim? Can you post the output of:
$ dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; (flags|SERVER):'
On my system, I see:
$ dig +noall +stats +comment -t mx et.lindenberg.one | grep -E '^;; (flags|SERVER):'
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
Note the "ad" bit in the response *flags*, and "127.0.0.1" for the
*SERVER*. I have a validating local resolver.
Without DNSSEC-valid MX records for the destination domain, and
DNSSEC-validated A/AAAA records for the selected MX host, TLSA records
won't even be looked up, let alone used, and SNI will not be sent
(unless explicitly requested in the Exim configuration).
On Sun, Jul 07, 2024 at 07:56:29PM +0200, Wolfgang via Exim-users wrote:
> So Victor just told, that the SNI problem is related to the crypto
> fail problem.
Yes, because the default certificate at the destination has an odd
keyUsage extension, that only support the obsolete RSA key transport,
and not ephemeral key exchange, so it is, for example, incompatible
with TLS 1.3, and would require the use of the deprecated RSA key
exchange with TLS 1.2.
On Sun, Jul 07, 2024 at 11:47:57PM +0200, Wolfgang via Exim-users wrote:
> I just use another subject for the SNI issue, as this seems to be independent from the
> DANE-Problem with GNU-TLS.
It isn't, all the issues are linked.
> As it looks right now this causes the DANE-Problem, as the testserver
> gives another cert, when no SNI is sent and that cert reveals the
> problems with GNU-TLS.
Or, more likely, you're not using DANE at all, either because it is not
enabled in your Exim configuration, or because you don't have a
validating local resolver in /etc/resolv.conf, or it does have
"options trust-ad" (needed on recent glic systems).
Which then leads to no default SNI, and then to the problematic
keyUsage.
> But now I have to figure out, why my servers are not sending SNI in
> "Client Hello".
DANE is not actually taking place.
> I did a tcpdump on my test environment, sending mails to a couple of domains, DANE secure, without
> DANE, but enforcing STARTTLS and such, allowing STARTTLS.
> I did this three times, using different compiled exims for the same configuration:
> - the distribution original exim "Exim version 4.96"
> - my own compiled exim with OpenSSL-GNU from debian "Exim version 4.97.1"
> - my own compiled exim with self compiled "openssl-3.3.1" "Exim version 4.97.1"
> all connections were established without using SNI, just a plain "Client Hello" in the dump!
>
> Two servers with "Exim version 4.93" are also not sending SNI in TLS.
You really should have included the "Transport Layer Security" portion
of the packet that includes the TLS Client Hello. But if the problem
is at the DNS layer, this is not surprising, so perhaps not needed.
--
Viktor.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
