On Fri, May 29, 2020 at 10:36:42PM +0100, Jeremy Harris wrote:
> > Note (4) and (5) happen in parallel. Ideally ??? would be a bad_certificate
> > alert, but it is sometimes a TCP reset. I’m not a TCP expert, but I believe
> > this is because the client writes data (“GET / ...”) the server never
> > consumes.
Fortunately, at least for SMTP, the issues David raises are not likely
to be seen because:
- The protocol is not unidirectional, client and server take turns.
- The server sends the first AppData (220 greeting), so the
NewTicket message is read by the client, or any complaints
about the client certificate...
However, if the server has something to send during the data transfer
phase (e.g. attempts to rekey the connection), then the client could
perhaps not be polling the server socket for incoming traffic, and
a deadlock may be possible.
Such mid-transfer traffic from the server is rather unlikely in
practice, so I don't think there are immediate concerns for Exim or
Postfix, but keeping an eye on the server socket for incoming data may
be prudent. If a zero-length SSL_read() when the socket appears
readable takes care of any unexpected non-application-data, then
it should be fairly easy to incorporate into the I/O loop.
- If the remote socket is readable, but you're trying to write
and don't yet expect to read, do a zero-byte read, but since
this may not drain the read queue of unexpected app-data,
don't poll for read again unless the write side has made
some progress.
- If you have something to write, and the socket is writable, write it.
- If you are expecting to read something, read a chunk of data,
paying attention also to SSL_ERROR_WANT_WRITE.
At least in Postfix, the socket is non-blocking once TLS is enabled and
we're relying on SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE to provide
appropriate retry signals, and then wait for the corresponding
condition.
Handling out-of-turn app-data (mid-data-transfer server errors) requires
a bit more care, but the server is supposed to wait until the client
sends '.'. Early SMTP error responses are unreliable even without TLS.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
