Re: [TLS] interop for TLS clients proposing TLSv1.1

[Martin Rex <[e-mail]>]

Geoffrey Keating wrote:
> 
> 
> > Does anyone (SSL Labs, Opera, others) have any figures/stats about the
> > current "TLSv1.1 version (in)tolerance" for TLS servers on the public
> > internet?
> 
> I find that about 1.4% of servers will refuse to connect using a TLS 1.2
> hello but will connect using a TLS 1.0 hello.  Some of those might be
> unhappy about something else in the TLS 1.2 hello (extensions, for
> example).  The other 99% accept a TLS 1.2 hello, even though only a small
> fraction (about 0.15%) actually supports TLS 1.1 or 1.2.
> 
> > The TCP RST in the above situation, as described in Stevens' Network
> > Programming, Section 7.5, Socket Option SO_LINGER, only indicates the
> > specific SO_LINGER setting that the server had used for his side
> > of the connection / his socket (Fig. 7.10  close() l_onoff=1, l_linger=0)
> > 
> > The SO_LINGER setting for a socket is entirely at the discretion of each peer
> > and closing the socket immediately after sending a fatal alert is exactly
> > what the TLS spec suggests:
> > 
> >    http://tools.ietf.org/html/rfc2246#section-7.2.2
> > 
> >    7.2.2. Error alerts
> > 
> >    Error handling in the TLS Handshake protocol is very simple. When an
> >    error is detected, the detecting party sends a message to the other
> >    party. Upon transmission or receipt of an fatal alert message, both
> >    parties immediately close the connection. 
> > 
> >           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!
> 
> RFC 793 says, in section 3.5, that a connection is closed by sending a
> FIN.  A RST is not a close of the connection but an abort; as RFC 793
> says, "Such a message indicates to the site B TCP that something is
> wrong, and it is expected to abort the connection."

Your on the wrong page, see RFC1122 Section 4.2.2.13.
Sending RST on cluse, indicating loss of data (that includes future
loss of data).

When not lingering on close, the server closes and destroys the socket
immediately, there will not be a graceful three way handshake and the
server does not care whether the data is received by the recipient,
not even whether the data is delivered by the network.


> 
> However, the question of how to close the connection is secondary,
> because it should not have been closed in the first place; as the blog
> entry says, "The server isn't supposed to behave this way---it's
> instead expected to simply reply using the latest HTTPS protocol
> version it supports".  You can't really expect software that's broken
> in one way to work perfectly in all other ways...
 

You're missing the point.  The blog is describing a reconnect fallback
implemented in WinINET, and writes that the fallback fails to work
because the server behaves incorrectly.  This is wrong,  The server
behaviour is perfectly fine, but the described reconnect fallback
logic is flawed.


-Martin