Re: [TLS] Sending fatal alerts over TCP

[Martin Rex <[e-mail]>]

(clarified & re-sent)

Martin Rex wrote:
> 
> Florian Weimer wrote:
> > 
> > TCP has the property that connection shutdowns can overtake application
> > data if connections are used in full-duplex mode.

No, it can not (for implementations conforming to rfc1122).

>From rfc1122, Section 4.2.2.13 "Closing a connection":

     http://tools.ietf.org/html/rfc1122#page-88

     A host MAY implement a "half-duplex" TCP close sequence, so
     that an application that has called CLOSE cannot continue to
     read data from the connection.  If such a host issues a
     CLOSE call while received data is still pending in TCP, or
     if new data is received after CLOSE is called, its TCP
     SHOULD send a RST to show that data was lost.

"Application calling CLOSE" refers to calling shutdown()
(rather than close(), which would destroy the socket handle)
in terms of BSD sockets.

That paragraph from rfc1122 means that a TCP implementation could
decide to treat shutdown(socket,SHUT_WR) and shutdown(socket,SHUT_RD)
always and exactly the same as shutdown(socket,SHUT_RDWR),
i.e. not support a unidirectional/partial closure.


> 
> > Here's an example:
> > 
> > (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.

Correct.


>
> > When it tries to read data, it will receive ECONNRESET.

That can not happen _unless_ some buggy code in the application on Y
called shutdown(socket,SHUT_WR) when being faced with EPIPE on send().

>
> > Note that this behavior is not related
> > to the SO_LINGER socket option.

I believe this is incorrect.  If X is using SO_LINGER, then
(2) will cause X to send a TCP FIN to Y, which the TCP
implementation on X ought to translate into a regular
End-Of-File on recv(), rather than ECONNRESET.


>
> > According to the socket API sepcification, there is no way
> > to access the initial TLS alert.

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


If you have some app on Y _not_ seeing the fatal TLS alert
(but you saw it coming in on the network with a tool like Wireshark,
then there is probably incorrect app code that erroneously called
shutdown(socket,SHUT_WR) while using a TCP implementation that
does not support a full-duplex close, or an incorrect app that
called shutdown(socket,SHUT_RDWR), maybe as an inappropriate
knee-jerk reaction of being faced with EPIPE on send(),
prior to trying to recv() the alert.


-Martin