Re: [TLS] Sending fatal alerts over TCP

[Bodo Moeller <[e-mail]>]

> > > (1)  X sends a fatal TLS alert to Y
> > > (2)  X shuts down the connection
> > > (3)  Y sends data to X
> > > (4)  X receives from Y, sends RST to signal data loss to Y
> > > (5)  Y receives RST
> > >
> > > (6) At this point, when Y tries to send further data,
> > > it will receive EPIPE from the sockets API.
> > > When it tries to read data, it will receive ECONNRESET.
>


> As long as Y does not call shutdown() on the socket, it will
> receive all data that arrived on the socket prior to seeing
> End-of-file (X with SO_LINGER) or ECONNRESET (X without SO_LINGER)
> on recv().
>
>
That's not right.  Upon receiving RST, Y's TCP will reset the state for
this connection and discard any data already buffered; no further data can
be received by the application (in this case, by the TLS implementation);
check RFC 793 for RST processing details.  If X doesn't want that, it must
not send an RST.

(With a fatal alert, that doesn't sound *that* problematic because there's
a problem anyway.  I've seen TLS servers send RSTs instead of cleanly
closing the connection when there was *no* error, which is very bad because
then you depend on client-side scheduling -- if the TLS client isn't able
to process the response before the TLS connection is killed, you have a
problem.)

Bodo