Re: [TLS] Should we require implementations to send alerts?

[Kurt Roeckx <[e-mail]>]

On Wed, Sep 16, 2015 at 01:54:20PM +0200, Florian Weimer wrote:
> On 09/16/2015 01:51 PM, Henrik Grubbström wrote:
> > On Wed, Sep 16, 2015 at 12:02 PM, Florian Weimer <[e-mail]> wrote:
> >> On 09/15/2015 06:29 PM, Nico Williams wrote:
> > [...]
> >>>
> >>> But if you have a fatal error you'll be closing immediately anyways.
> >>> Does sending the fatal alert cause a problem other than increase the
> >>> likelihood of RSTs?  What is the alternative considering that the next
> >>> step is to close the connection anyways?
> >>
> >> I'm trying to explain that any requirement to send fatal alerts will be
> >> difficult to implement.  With the BSD sockets API, the only way to do
> >> that reliable is *not* to close the socket immediately, which is
> >> apparently not what you (or existing APIs) expect, and which is where
> >> the difficulty lies.
> > 
> > What about SO_LINGER?
> 
> With full-duplex connections, it does not make a difference.  TCP will
> still detect a data loss event, send the RST segment, and discard the
> queued fatal alert.

>From what I understand, the RST is send after calling close(),
shutdown(SHUT_RD) or shutdown(SHUT_RDWR) and not all data has
been read from the socket or more data is received.

So my understanding of making sure the other end receives it is
calling close() when read() returns 0 (or an error).  You might
want to do shutdown(SHUT_WR) before that to indicate you're not
going to send anything anymore, but that should have no effect
since the other end is supposed to close the connection after
receiving the alert anyway.  You might want to have a timeout and
close it anyway.  If read() returns any data, you should of course
throw it away.

It seems that when you using SO_LINGER you might end up turning
your non-blocking socket into a blocking one on close() (or
shutdown?), and can't even tell if it was received succesfully or
not.

But I wonder in which cases it's important to receive the fatal
alert.  I guess it's the cases where it can tell you that
connecting again might work, and so would only be during the
handshake.  The only case I can think of is something like "client
certificate required", and as far as I know we don't even
currently have something that says that explicitly.


Kurt