On Tue, Feb 02, 2021 at 10:44:34AM -0500, Curtis Maurand wrote:
> Jumping in as an observer with 25 years of admin experience with
> public facing equipment and servers. This problem seems more of a
> problem with the tls libraries.
The SSL_shutdown() behaviour in sufficiently recent OpenSSL versions is
fine, the TLS library is doing its job correctly.
The main issue was incomplete documentation of how to use TLS close
notify (SSL_shutdown()) correctly, and rather poor TLS support in
Sendmail that dates back to substantiall older OpenSSL releases and has
not been actively maintained for some time.
TLS shutdown can be unilateral in most applications where neither
half-closed connections nor a return to cleartext after TLS are
expected. In a few applications TLS shutdown needs to be 2-sided, this
supports more complex communication patterns than required for SMTP.
The OP has chosen to perform the 2-sided TLS shutdown in his Sendmail
fork, needlessly waiting for a close_notify from the remote peer. He's
free to do that, but there's no need for Postfix to emulate this. For
history buffs, Postfix used to do the same in the original TLS code
written by Lutz Jänicke, but we dropped the needless lingering some
releases back, it just reduces the available concurrency of the SMTP
server and client processes by keeping some needlessly idle.
When an SMTP server or client elects to close its write-side of the
communication channel it is never the case that there is still data
remaining to be read from the peer for which TLS is providing truncation
attack protection. So sticking around waiting for the peer's
close_notify is pointless in SMTP.
> it’s not up to the app to close the tls connection. that layer is
> below the application layer. when the application terminates its
> connection the tls library should be smart enough to close the socket
> properly itself.
Actually, it is up to the application to signal that nothing further
will be written. This supports half-close, and also makes it possible
to choose whether to wait for the close_notify from the peer.
One can layer simpler interfaces above the TLS library that assume
a particular data flow, and automatically handle shutdown in the
expected way, but the general case requires explicit signalling.
> this seems to be a problem of the tls layer not playing nicely with
> its peers. the smtp protocol is clear about its connection
> termination handshake. it doesn’t seem like the tls layer is.
The TLS layer is correct as implemented, it supports half-close,
which can e.g. be useful in HTTP.
OpenSSL also provides a BIO interface to SSL that manages the underlying
sockets, performs automatic shutdown management, ... applications that
don't want to be concerned with such issues can use the BIO_f_ssl(3)
interface, which also supports buffering, and other higher-level stream
abstractions.
MTAs, such as Sendmail, Exim, Postfix have typically elected to directly
use the underlying message-oriented SSL interface for more direct
control of the transmission channel.
--
Viktor.
