On Fri, May 29, 2020 at 5:36 PM Jeremy Harris <j...@wizmail.org> wrote:
> On 29/05/2020 21:59, David Benjamin wrote: > > Moreover, in a client-speaks-first protocol, the error now comes after > the > > client has already sent its request. This is not only a behavior change > but > > makes it unreliable over TCP. TCP sees: > > > > > > 1. > > > > Client: write(ClientHello); > > 2. > > > > Server: read(ClientHello); write(ServerHello..Finished); > > 3. > > > > Client: read(ServerHello..Finished); write(Certificate..Finished); > > 4. > > > > Server: read(Certificate..Finished); write(bad_certificate); close(); > > Rather than close(), the server should shutdown(SHUT_WR) > > > 5. > > > > Client: write(“GET / ...”); read(???); > > > > > > 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. > > ... because, having solely notified that it will send no more, the > server is free to continue to read from the socket. > The server's application logic has no reason to continue to read from the socket. This behavior typically comes from layers above the stack. From the server's perspective, the TLS library just said the handshake failed. It required a valid client certificate during the handshake, and the client did not produce one. This is fatal to the connection, so the server has no reason to keep it around and no application data to read or write. The issue is that we've tweaked the I/O patterns in TLS 1.3 such that the resulting overall behavior interacts badly with TCP. The server could shutdown(SHUT_WR) and intentionally hold on to the socket and drain data, in order to get the alert through. That's one of the options I described: > It seems the only fix is for the server to keep the connection alive for some time after the failure, maybe draining some bytes from the application, with some limit before giving up and resetting if the client seems to be writing a lot of data without ever reading. This would need to be quite up the stack. We have not implemented this. This, however, has DoS implications for the server and is a very different API shape from many current TLS libraries. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
