On Sat, Oct 30, 2021 at 10:46:24AM +0300, Evgeniy Berdnikov via Exim-users wrote:
> > This seems like a footgun combination of configuration options. [...]
>
> How Exim is doing TLS fallback is described here:
>
> https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html#SECTclientTLS
>
> As I understand, peer's certificate validation failure is one variant of
> general TLS negotiation failure, resulting in fallback to plain text if
> tls_tempfail_tryclear option of SMTP transport is "true" (default).
Yes, but this is an "opt-in" failure mode. You don't have to try to
verify, and even if you try to verify you don't have to choose to abort
the handshake when verification fails.
Note that X.509 certificate verification lies outside of TLS, and is in
an entirely separate library in some TLS stacks. Certificate
verification failure is only a TLS handshake failure if one chooses it
to be.
The only reason to abort the handshake on verification failure is if you
insist on a secure connection, and then you'd better not fall back to
cleartext which would be just absurd. Either require a secure
connection, or don't, ... the combination of behaviours makes no sense.
Yes, Exim currently makes it possible, but that such booby traps for the
user are design errors, when they're not (as in this case) just
implementation bugs.
--
Viktor.
P.S. In Postfix we never abort a TLS handshake due to verification
failure even when authentication is required. Instead we let the
handshake complete, and then, if verification was required, but did not
succeed, politely terminate the connection (by sending QUIT) without
sending the message.
Some day I may define an SMTP extension for in-band signalling of
authentication failures, that servers can offer if they want near
real-time notification that clients are seeing problems with the
server certificates.
