Re: [TLS] Sending fatal alerts over TCP

[Bodo Moeller <[e-mail]>]

On Wed, Dec 21, 2011 at 8:13 PM, Martin Rex <[e-mail]> wrote:


> > > > > (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.
>

Specified processing for X in (CLOSED):
>


>    If the incoming segment has an ACK field, the reset takes its
>    sequence number from the ACK field of the segment, otherwise the
>    reset has sequence number zero and the ACK field is set to the sum
>    of the sequence number and segment length of the incoming segment.
>    The connection remains in the CLOSED state.
>
>
> which means that X must send an RST with a SEQ number of 0!
>

The segment sent by Y in step (3) will have the ACK bit set, so the RST
sent by X in (4) will have the appropriate sequence number that causes Y to
accept the RST in step (5), and thus to discard all data.

(By the way, I think the Linux TCP implementation will send a RST in that
situation if close() has been used to shut down the connection regardless
of SO_LINGER settings.  Stevens doesn't describe that particular TCP
implementation.)

Bodo