[Top] [All Lists]

Re: [ietf-smtp] TLS1.3

2020-05-05 21:11:57
On Tue, May 05, 2020 at 08:03:53PM -0400, Sam Varshavchik wrote:

So after reading the following:

# When a certificate was set using the SSL_CTX_use_certificate(3) family of  
# functions, it will be sent to the server. The TLS standard requires that  
# only a certificate is sent, if it matches the list of acceptable CAs sent 
# the server. This constraint is violated by the default behavior of the  
# OpenSSL library.

This appeared to me like a client that was configured with a certificate for  
some other host, but sending it in error, here, and the server rejecting the  
connection for that reason.

No that's not it.  And actually, OpenSSL is generally correct in using
the client certificate anyway.  The server may, e.g., not trust any CAs,
and verify client certs by fingerprint.  A client that is an MTA, and
not some user worried about privacy leaks has nothing to hide in
sendings the only certificate it is configured with.  The specification
assumes a narrow trust model that does not match reality.

Problematic TLS implementation have been quite common, historically. For a  
long time I was seeing frequently TLS-related misconfigurations with SMTP  
servers. I lost count how many servers I saw advertising STARTTLS but  
choking when taken up on their offer:

EHLO hythere Ok.
250 DSN
450 Not now, maybe someday.

Indeed a minority are misconfigured in this manner.  When TLS is
optional (opportunistic and unauthenticated), Postfix will retry
in the clear when this happens, provided the message has been in the
queue for at least one retry interval.

At one point I had to carefully implement an adaptive, transient TLS  
blacklist: ignore the server's STARTTLS if you have a prior record of the  
server failing to negotiate a TLS connection.

See above.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>