On Fri, May 29, 2020 at 5:01 PM David Benjamin <david...@chromium.org> wrote: > > Hi all, > > > As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some > interesting interactions with TCP. We thought we’d document these and send a > note here. In general, we've found that TLS implementations need to be wary > of post-handshake messages and “unexpected” transport writes. This > unfortunately also includes some server handshake alerts. > > > TLS APIs > > First, some background on APIs for TLS libraries. TLS is often deployed > “transparently” underneath a TCP-based protocol. HTTPS sandwiches TLS between > HTTP and TCP, etc. By and large, reads and writes over TLS are one-to-one > with reads and writes over TCP. > > > TLS APIs and callers can subtly rely on this. Some libraries expose an > interface like the POSIX sockets API, including non-blocking behavior. If the > transport is blocked on I/O, this is surfaced as an error for the caller to > retry later. Importantly, the library cannot drive transport I/O on its own. > The caller must drive the operation to completion. Other APIs transform bytes > and leave I/O to the application.. Any TCP writes triggered by TLS reads and > vice versa are even more directly part of the API surface. In contrast, > sometimes the TLS library can drive I/O itself. For example, a Go TLS > implementation can do background work in a goroutine.
In my experience the issues are thorniest when dealing with blocking sockets. Libraries using nonblocking sockets have to signal to the application that they want IO to happen during the handshake, and can use that same mechanism at later times, particularly for rekeying. Libraries with blocking behavior are unfortunately in a difficult position if they imitate a POSIX API and have no means to drive I/O. One possible dirty trick is to set nonblocking on an owned socket and translate the blocking call into a select or poll based loop that issues both writes and reads until enough is read or written. Note that the real corner case is unanticipated needs to read from the socket: the library has control when it needs to write. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
