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 <fwei...@redhat.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
