Re: [TLS] TLS 1.3 and TCP interactions

[Watson Ladd <[e-mail]>]

On Fri, May 29, 2020 at 5:01 PM David Benjamin <[e-mail]> 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.