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. If it arrives at the server TCP stack before close(), the socket > is closed with unread data. If it arrives after close(), the socket > receives data after close(). TCP appears to consider either condition an > application protocol error and triggers a reset shortly after sending the > alert. -- Cheers, Jeremy _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
