On 29/05/2020 22:52, David Benjamin wrote: > 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.
Perhaps not, though I suggest it is valuable to it for debug and development to be able to see the client's reaction to the shutdown. However, you ignored the value of the shutdown() action not resulting in a RST. That means that the client view becomes deterministic; your "read(???)" in the close/RST scenario becomes "read(error, ALERT:bad cert)". -- Cheers, Jeremy -- Cheers, Jeremy _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
