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

From: Martin Rex <[email-masked]>
Date: Wed, 21 Sep 2011 22:48:33 +0200 (MEST)

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

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 21 Sep 2011 23:32:12 +0200

> current "TLSv1.1 version (in)tolerance" for TLS servers on the public

This week's test of 609726 servers gave these numbers:

   * 1.145% of the probed servers were version intolerant for at least one  
of the current TLS versions (1.0, 1.1, 1.2)
   * 1.742% were extension intolerant for the same versions
   * 1.136% belonged in both groups

This gives an estimated total of 1.751% that are either version and/or  
extension intolerant for the currently defined TLS versions.

These numbers have been decreasing during the past year and a half, around  
January 2011 it was 1.951% just for the version intolerant, 2.657% in may  
2010 (the extension numbers are not as detailed for those runs).

Most of the version intolerant are intolerant for TLS 1.1 and TLS 1.2, but  
some are SSLv3 only servers that are also intolerant for TLS 1.0. There is  
even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn"  
as the hostname).

If Opera encounters an intolerant server it will shut down the connection  
and fall back step by step.

Essentially, the fallback sequence is currently	

   TLS 1.0 + extensions
   TLS 1.0 w/o extensions
   SSL v3

Upwards it is v1.1 and v1.2, and fallback if negotiation failed.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Sep 2011 00:47:14 +0300

Hi Yngve

> even a 0.007% share that support TLS 1.1 (quite a lot of which has "vpn"  

By "version intolerant" do you mean that you're sending a TLS 1.1 or 1.2 handshake message and the server rejects it?

If you send a TLS 1.0 handshake message, with the version field of the ClientHello showing 1.2, what portion of the servers would reject that (rather than just replying in TLS 1.0)?

Is that something you measure?  If the portion is very low, it could be feasible to implement a client without fallback behavior.

Yoav

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 00:24:40 +0200 (MEST)

Yoav Nir wrote:
> 
> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
> >
> > Martin Rex <[email-masked]> wrote:
> > >
> By "version intolerant" do you mean that you're sending a TLS 1.1
> or 1.2 handshake message and the server rejects it?

> 
> If you send a TLS 1.0 handshake message, with the version field of the
> ClientHello showing 1.2, what portion of the servers would reject that
> (rather than just replying in TLS 1.0)?

The latter is what I'm actually interested in
(but seem not have been sufficiently clear about).

Sending TLSv1.1 or TLSv1.2 in the Record Layer for ClientHello
constitutes a version-intolerant client (or more appropriately
it indicates a client that is unwilling to talk TLSv1.0).

Other than a very last resort in trying to get a TLS handshake succeed
I see little value in sending a value above TLSv1.0 in the protocol
version field of the SSL3 Record carrying the initial ClientHello
on a connection.

> 
> If the portion is very low, it could be feasible to implement a
> client without fallback behavior.

Since "fallback behaviour" is dumped entirely on the app calling
the TLS implementation, I expect "clients without fallback behaviour"
to be the norm for programmatic clients.

The version intolerance stats for public servers on the internet
is not really representative.  I expect a significant amount of
version-intolerant servers to not be publicly accessible.

I'm seeing a desire to raise the number of TLS peers use TLSv1.1
with CBC-based cipher suites and explicit IVs, and I'm also
seeing a residual, non-negligible number of version intolerant
TLS servers interfering with original design of TLS protocol
version negotiation.

I would appreciate a solution for decoupling of these two
issues so that clients without fallback capabilities
become able to use TLSv1.1 right away, while neither facing
new interop problems or having to wait 5+ years for sufficient
of the version intolerant TLS servers to die.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 00:30:48 +0200 (MEST)

> extension intolerant for the currently defined TLS versions.

OK, I'll try to be more specific about the numbers that
*I* would be interest in (in case you could extract from your data):

When sending an SSLv3 ClientHello (i.e. {0x03,0x00} at the record layer),
how many servers abort immediately, depending on the value of the
client_version:

    for client_version = { 0x03,0x00 }   (SSLv3)
    for client_version = { 0x03,0x01 }   (TLSv1.0)
    for client_version = { 0x03,0x02 }   (TLSv1.1)
    for client_version = { 0x03,0x03 }   (TLSv1.2)

and how many continue the handshake but fail the finished macs?

-Martin

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 22 Sep 2011 00:44:29 +0200

On Wed, 21 Sep 2011 23:47:14 +0200, Yoav Nir <[email-masked]> wrote:

> By "version intolerant" do you mean that you're sending a TLS 1.1 or 1.2  
> handshake message and the server rejects it?
>
> Is that something you measure?  If the portion is very low, it could be  
> feasible to implement a client without fallback behavior.

The testing is performed using two record protocol versions: Either 3.0 or
3.1 (starting with 3.0), depending on what actually works

The record version is supposed to be the lowest version the server is  
known to support. At present all clients are AFAIK sending 3.1, unless  
they are offering 3.0 as the highest version, or is trying 3.0 in  
combination with 3.1.

Intolerance is considered present if the server does not negotiate a
version it is known to support, when a higher version than supported is
sent in the Client Hello (e.g 3.1 is known, sending 3.2), and there is
some form of handshake failure (including abrupt connection shutdown)
either as the handshake is sent, or during the handshake, before it is
completed.

There are some servers (0.487%), for example www.mozilla.com, that will
not negotiate TLS 1.0 (0.487%) or TLS 1.1 (0.217%) if the record protocol
is 3.0.

Extension intolerance is detected in a similar fashion.

---

From: Geoffrey Keating <[email-masked]>
Date: 21 Sep 2011 15:54:35 -0700

> current "TLSv1.1 version (in)tolerance" for TLS servers on the public

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.

>    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."

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...

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 22 Sep 2011 01:19:38 +0200

> and how many continue the handshake but fail the finished macs?

I am currently not registering data that detailed (although I do register  
results for each tested client_version value tested, the results are not  
that fine-grained), and IMO it does not really make that much a difference  
(to the client) if the server just shut down the connection, or failed the  
finished message; establishing the connection still failed.

As mentioned earlier I do register servers that refuse to accept a SSL v3  
record protocol for the Hello, but require a TLS 1.0 instead (the number  
of servers that require that, and are included in the above version  
intolerance count is 29, 0.005 percentage points)

One case where we do (implictly) get a failure during the finished mac, is  
for the 0.117% of servers that mirror any version back, even if they do  
not support it.

The number of servers that require the RSA client key exchange version  
field to be the same as the negotiated version, not sent version, is about  
4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  
version field.

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 01:20:32 +0200 (MEST)

> 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.

> 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

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Sep 2011 01:50:35 +0200 (MEST)

Yngve N. Pettersen wrote:
> Martin Rex wrote:

Thank you very much for providing the information that have collected.
It's not that I urgently need exactly that information.  I'm mainly
trying to figure out what is the most interoperable set of "features" for
a ClientHello for a TLS client that is _not_ capable of reconnect fallback.

> 4.6% (April 2011; data not reliable since then :( ): about 27% ignore that  

Thank you very much for reminding me of this problem.  I had entirely
forgotten about this, and that number (4.6%) is quite disappointing.

Add to that the RSA client key exchange version bug that Microsoft
has shipped with Windows 7 SChannel for the renegotiation handshake,
where they check the premaster secret version against the proposed
version of the initial handshake instead of the proposed version
of the current handshake and you will get the bottom line that
suggesting the use of TLS version 1.1 or 1.2 through
ClientHello.client_version will result in a significant amount
of interop problems.

I really think we (the TLS WG) should provide a remedy to this awful
situation for the TLS protocol version negotiation in the installed base.

> intolerance count is 29, 0.005 percentage points)

OK.  I personally don't see those as a problem because I consider
SSLv3 and TLSv1.0 equivalent when used with any of the regular
SSLv3 cipher suites plus rfc3268 AES.
 
> for the 0.117% of servers that mirror any version back, even if they do  

While being technically different, those will likely be covered by
a fairly conservative strategy of exclusively using either

   SSLRecord.protocol         = { 0x03,0x00 } 
   ClientHello.client_version = { 0x03,0x01 }

or

   SSLRecord.protocol         = { 0x03,0x01 } 
   ClientHello.client_version = { 0x03,0x01 }

for a client without reconnect fallback.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 21 Sep 2011 17:09:42 -0700

> not even whether the data is delivered by the network.

I think we're agreeing?  For the purposes of TLS, you definitely don't
want to do an abort by sending a RST, because it doesn't guarantee
that the alert gets delivered to the endpoint---even if it gets
physically sent, and it's not dropped in transit, the other end may
discard it before delivering it to the TLS layer (flushing its buffers
on receipt of a RST).

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 22 Sep 2011 22:25:44 +1200

Martin Rex <[email-masked]> writes:

>WinINETs behaviour, that WinINET behaviour should be fixed to allow MSIE
>users on Win7 to enable TLSv1.1 with less risk of interop problems.

I've been told this is an artefact of schannel/wininet layering, that there's
no way for schannel to communicate the necessary info to wininet, so it
responds with a RST.  There are other situations where it does this as well,
not just protocol-version issues.  There's apparently no easy way to fix this
without considerable re-architecting.

Peter.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 26 Sep 2011 13:30:37 +0000

> situation for the TLS protocol version negotiation in the installed

Most vendors offer automated updates these days.  Deployments which are
not updated are likely to have other issues besides interoperability
problems.  Protocol fixes still do not end up in deployment.

I think we should try to figure out the reason before we try to work
around it.  If we're unlucky, the workarounds are broken in a similar
way, and we gain very little because vendors and deployments which use
arguably more secure protocol versions are still punished by an
incompatible installation base.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Martin Rex <[email-masked]>
Date: Mon, 26 Sep 2011 16:27:41 +0200 (MEST)

> problems.  Protocol fixes still do not end up in deployment.

The installed base of TLS is around 2 Billien endpoints (no kidding),
so any "updates" and new features should seriously take into account
how the installed base (in particular the part that is not going
to be updated) reacts to them.  Allergic reaction (=interop problems)
need to be avoided as much as possible.

It seems that no TLS client that propose TLSv1.1 or higher today
would want to do so without a reconnect fallback facility in place.
The problem of the reconnect fallback is, that it precludes a protected
negotiation of the TLS version.

There seems to be only one extensibility left in TLS that is sufficiently
robust to be usable in _all_ scenarios (and that allows for a real
negotiation inside TLS rather than an application level fallback after
a TLS handshake failure).

> around it.

TLS version negotiation (and the checking of the TLS version in the
RSA premaster secret) is sufficiently broken across the installed base
that we really don't need to know anything else.

A "nanny" spec that provide very detailed guidance about how an
alternative TLS version negotiation works, plus all the known issues
about the known defects in existing TLS version negotiation and how
thing MUST be done in future implementations, should be just fine
to address the problem ... and to bridge the 10-15 years that it
takes before all of the problematic TLS implementations, that
currently exist in the installed base, have died off sufficiently
so that the original TLS version negotiation (which is _not_ going
to be deprecated, just extended) can be expected to work as
originally intended.

>
> If we're unlucky, the workarounds are broken in a similar way,

It is not the original TLS version negotiation that is really broken,
but it seems to have been underexplained in a fashion that there was
apparent confusion among implementors about which protocol version
to use on the record layer for a ClientHello and which protocol
version to use (and to check) in the RSA permaster secret.

To address the problems apparent in the original installed base,
I believe that using a much clearer specification with the scope
limited to TLS version negotiation, plus real interop testing of
that extensibility feature should be sufficient.

Traditional SSL&TLS interop was done only in a limited fashion
and only about features that were implemented.  If anyone had
interop-tested the extensibility before shipping, they would
have realized their bugs.  It's a real pity that Microsoft did _not_
interop test their RSA premaster version check on renegotiation
handshakes before they shipped the TLS renegotiation fix for
win7/2008R2 (I haven't checked their older SChannels for this
characteristic).

>
> and we gain very little because vendors and deployments which use

We can not do anything about the lack of features in the installed
base, other than _not_ let that stop us from using better features
with newer peers.  Currently, the installed base is a _real_ problem
for TLS clients to perform a protected TLS version negotiation,
and realizing that, the TLS WG should provide an alternative.

-Martin

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Tue, 27 Sep 2011 01:12:34 +0200

> negotiation of the TLS version.

As long as there is no way to tell if a server is negotiating version  
correctly, then we do need a fallback mechanism.

It is, however, a mechanism that for HTTPS, at least, is becoming less  
needed, as I indicated earlier in this thread.

I also think we have a mechanism now that can be used as an indicator that  
the server can negotiate version in the required fashion, without needing  
a fallback system: The Renegotiation Indication Extension.

The Renego specification contain a reminder about version and extension  
tolerance being required. (Yes, I lobbied for the inclusion of that  
particular text).

My testing indicates that the tolerance is included in most Renego patched  
servers. The failure rate in my sample is 0.092% up to and including TLS  
1.2, mostly extension intolerance. The version intolerance for version  
code 3.x >= 3.4 is 0.049%. There is some problems with the 4.x+ range,  
though, due to a missing patch at at least one vendor.

(To compare the numbers, this is slightly less than the number of servers  
that may break if the patch suggested for the BEAST issue is implemented,  
according to my testing.)

My suggestion is that clients that use a fallback policy to an older  
version than their highest supported version, in case negotiation fails,  
should always negotiate with their highest version indicated if the server  
is detected as having been Renego patched, and then not fall back in case  
negotiation fails.

That would essentially eliminate the version rollback potential, at least  
without a weakness being discovered in the protocol integrity check itself.

One way to implement such a policy is that the client starts with TLS 1.0  
+ extensions, and only upgrade to TLS 1.1 or TLS 1.2 if it detects that  
the server is renego patched.

Alternatively (and I prefer this), the client can start with a higher  
version, and fall back as needed (currently for 1.8% of the sites), but go  
back up if the server is detected as Renego patched. This would have the  
benefit that the client saves time when connecting to 98+% of the servers,  
by not needing a fallback or an upgrade in a new connection.

Currently, 30% (463) of the (max) TLS 1.1 servers are not renego patched  
servers, only a single of the 133 registered TLS 1.2 servers isn't  
patched. This group is 0.2% of the unpatched servers (39.9%).

I doubt that any other mechanism will work better, and deployment will be  
at least 3 years behind the Renego curve, and will probably have a lower  
server deployment rate than Renego.

Let's see if we can work with what we have, before we design a new  
mechanism.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Bill Frantz <[email-masked]>
Date: Mon, 26 Sep 2011 16:32:37 -0700

I would add on this topic:

Browsers should refuse to display their highest security UI 
indicators if they negotiate a version of TLS with known flaws.

This suggestion would apply to SSL3/TLS0 today.

Since modern browsers are either automatically updated (Chrome) 
or updated regularly with automatic checking mechanisms (Safari, 
Firefox, Explorer) this policy can be quite dynamic. 
Organizations which buy high-security certificates will have a 
strong incentive to upgrade their servers. Other users, perhaps  
e-commerce sites using credit cards, do not need as high a 
quality of security and can be a bit behind on the security 
update treadmill.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032

---

From: Martin Rex <[email-masked]>
Date: Tue, 27 Sep 2011 01:44:22 +0200 (MEST)

> tolerance being required. (Yes, I lobbied for the inclusion of that  

I know that this was the original plan.

But these nice plans were foiled when Microsoft shipped their
implementation of rfc5746 with KB980436.

In retrospect, we ought to have required in rfc5746 to entirely
disable the version checking for the RSA premaster secret on the
Server side...

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 27 Sep 2011 09:01:14 +0200

On 09/27/2011 01:32 AM, Bill Frantz wrote:

> Browsers should refuse to display their highest security UI indicators
> if they negotiate a version of TLS with known flaws.

This seems like the best strategy to force servers to upgrade.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 27 Sep 2011 10:10:26 +0300

> This seems like the best strategy to force servers to upgrade.

I agree completely. If the browser vendors just agree to this, SSLv3 and TLSv1.0 could be phased out gracefully leaving us with TLS 1.1 and TLS 1.2 only. Since with two versions there cannot be any unsupported versions in between, it would effectively resolve the mentioned version negotiation problem in current TLS for the time being. (until new TLS versions come up)

Juho