Re: [TLS] Sending fatal alerts over TCP

[Nico Williams <[e-mail]>]

Stevens suggests[0] doing a shutdown(2) of SHUT_WR then read(2)ing or
select(2)ing (or more modern equivalent) for read events on the same
socket to wait for the FIN|ACK from the peer; read(2) is supposed to
return 0 at that point (though I suppose it could also actually read
data if there's data to be read, as only the write-side of the socket
will have been shutdown at that point).

That wouldn't be an indication that the application received the fatal
alert, of course.  Nothing short of waiting for the peer to close its
end of the socket will do, but we can't wait forever.

Setting SO_LINGER with a zero l_linger is out, and a non-zero value is
useless unless the thread is willing to block in close(2) -- a
terrible waste of resources.

It may well be that the best thing to do is to shutdown(socket,
SHUT_WR) then queue up the socket for a later close(2) with SO_LINGER
and zero l_linger.  This gives the peer application a pretty good
chance to receive the fatal alert and close the socket normally, while
also limiting resource usage on the side that sent the alert.  And if
you already have an event-based async I/O framework you can trivially
set a timer upon which to close() the socket, and even process any
further data sent by the peer.

[0] Unix Network Programming volume 1, 2nd ed., section 7.5, page 189
/ fig. 7.8.

Nico
--