On Sun, Jul 07, 2024 at 03:59:30PM +0100, Jeremy Harris via Exim-users wrote:
> On 07/07/2024 14:31, Viktor Dukhovni via Exim-users wrote:
> > So is sure seems like Exim DANE with GnuTLS fails to set the TLSA base
> > domain as the SNI name, while the Exim with OpenSSL does take care of
> > that...
>
> I assume you're inferring that from a test of poking that site
> with/without an SNI, independent of Exim use?
Yes, since, as I believe you're aware, I largely lurk on this list unless
some DANE, TLS, or OpenSSL issue comes up, but I am not an Exim user.
When I don't send SNI, I see a non-matching certificate with a
problematic key usage, while with SNI, I see the correct chain.
> Meantime, hunting through the Exim project regression testsuite, this (SNI sending)
> is tested by case 5802, subcase "t1@???". The SNI received by
> the server end of the connection is logged, and the log compared against a golden
> file for the testcase.
What the server's TLSA records in that case? Could the use of SNI
depend on usage DANE-EE(3). In this case all the TLSA records are "2 1 1".
Also the TLSA records are behind a CNAME:
_25._tcp.mx06.et.lindenberg.one. IN CNAME _tlsa.lindenberg.one.
_tlsa.lindenberg.one. IN TLSA 2 1 1 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d
_tlsa.lindenberg.one. IN TLSA 2 1 1 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4
_tlsa.lindenberg.one. IN TLSA 2 1 1 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270
_tlsa.lindenberg.one. IN TLSA 2 1 1 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03
_tlsa.lindenberg.one. IN TLSA 2 1 1 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888
_tlsa.lindenberg.one. IN TLSA 2 1 1 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d
_tlsa.lindenberg.one. IN TLSA 2 1 1 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10
_tlsa.lindenberg.one. IN TLSA 2 1 1 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba
_tlsa.lindenberg.one. IN TLSA 2 1 1 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7
This should not affect the TLSA base domain or SNI name sent. At this
point that "tshark" decode would be particularly helpful... My money
is still on either no SNI or the wrong SNI being sent.
> Both OpenSSL and GnuTLS pass, silently, this testcase on my laptop.
> I infer that the SNI is indeed sent over the connection (I've not gone
> as far as a packet capture). The GnuTLS version here is 3.8.5
Good to know that the problem may be a corner-case.
> Barring such a config error, the only other thing that comes to mind is an
> MITM (errrm, "security proxy") which happens to strip SNI. But that also seems
> unlikely.
The security proxy would not be able to impersonate the server well
enough for DANE to pass at any other site, to strip SNI it has to
terminate the TLS handshake, and then the cert chain simply won't match
the TLSA records. We can, with some confidence, rule out a security
proxy MITM..
--
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/
