[TLS] interop for TLS clients proposing TLSv1.1

[Martin Rex <[e-mail]>]

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?

A quick google search about the current client side situation for
proposing TLSv1.1 gave me (among others) to this information:

http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx


I am somewhat puzzled about the description of the reconnect fallback
described there for WinINET, and I believe that code/logic is wrong.

Quoting:

  If you examine the Encrypted Alert from the server, you will
  see that it contains the byte sequence 02 46, meaning
  Fatal Alert: Protocol Version.

  The server isn't supposed to behave this wayits instead expected
  to simply reply using the latest HTTPS protocol version it supports
  (e.g. "3.1 aka TLS 1.0). Now, had the server gracefully closed the
  connection at this point, it would be okay-- code in WinINET would
  fallback and retry the connection offering only TLS 1.0. The only
  downside would be performancethe extra roundtrips required for the
  new TLS 1.0 handshake will usually result in a penalty amounting
  to tens or hundreds of milliseconds.

  However, this server used a TCP/IP RST to abort the connection,
  which disables the fallback code in WinINET and causes the entire
  connection sequence to be abandoned, leaving the user with the
  Internet Explorer cannot display the webpage error message.

I believe that the Server's TCP/IP stack closing the connection
with RST is OK and perfectly permissible, and WinINET ought to
use a reconnect fallback here.

TCP RST with the meaning ("no one is listening") applies only
when an RST is received _instead_of_ SYN+ACK during TCP connection
establishment, with the effect of synchronous connect() failing with
an error or asynchrounous connect reporting an error on getsockopt()
after signalling writability.


In the above case, connect() had definitely successfully completed
-- they did send the ClientHello and even did receive an SSL Alert,
didn't they?)

But on top of that, the WinINET client seeing a fatal "protocol_version"
TLS alert is a "Blue's clue" on suggested retrying with TLSv1.0.


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. 

          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^!

I believe that the informtion in this blog is incorrect (about
what the server should do and about what WinINET should do) and
if my analysis is correct this information should be fixed or removed.

Likewise, if my analsis is correct and that Blog accurately describes
WinINETs behaviour, that WinINET behaviour should be fixed to allow
MSIE users on Win7 to enable TLSv1.1 with less risk of interop problems.


-Martin