Am 09.12.22 um 13:21 schrieb Jeremy Harris via Exim-users:
On 09/12/2022 10:43, Jeremy Harris via Exim-users wrote:The message looks like a courtesy note only, saying "I'm no longer prepared to TLS-renegotiate this sort of connection"; something that TLS endpoints have always been permitted to do for any class of TLS connection, and not implying a fault.Having looking around the code, it does look like the "TLS session" bitimplies Exim's smtp transport, with a conn fail. I'll investigate further.It'd help to get a debug trace for such a connection, so I can see detail on the TLS operations for re-creation of the condition.
It's not an exim error message, it upstreams from openssl into the logs.If a TLS connect is done to an outdated server using the old renegotiation methode,
openssl 3 ends the connection with that error messge.The root cause for this, is a change in the default config compiled intothe openssl executable. For OpenSSL 3 in 2021 they pulled in a patch to enable the check routine for this old renegotiation bug from 2009. In Openssl 1 it stayed turned off. Upgrading a os from openssl 1 to 3 will auto enable this check and bring this error
to the logs. so, if you use openssl 3 and see this error message:2022-12-09 10:23:22 1p3ZbF-003Bdo-2L == XXXXXXXX <X@Y> R=dnslookup T=remote_smtp defer (-37) H=mailin2.Z.z.z [a.b.c.d]: TLS session: (SSL_connect): error:0A000152:SSL routines::unsafe legacy renegotiation disabled
you need to contact the receiver and inform it , that hes using an outdated mailserver software with MITM enabling ageold security holes.
best reagards, Marius
OpenPGP_0x048770A738345DD3.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/