Subject: Re: [TLS] A request to the SChannel team

From: Yuhong Bao <[email-masked]>
Date: Fri, 11 Nov 2011 09:11:22 -0800

But the incorrect version checking on the premaster secret is definitely a bug, and I am CCing the TLS mailing list as they were encountering trouble with it.

Yuhong Bao
________________________________
> From: [email-masked] 
> To: [email-masked] 
> Subject: RE: MSDN Blogs: Contact request: A request to the SChannel team 
> Date: Fri, 11 Nov 2011 13:52:19 +0000 
>  
>  
> It takes only two clicks to enable TLS1.1 and 1.2; or run  
> http://go.microsoft.com/?linkid=9784203 
>  
>  
>  
> It’s not quite correct to call TCP RST fallback “proper” since the  
> server is misbehaving. But fallback is a WinINET behavior, not  
> SChannel, and it’s something we’re looking at. 
>  
>  
>  
> Thanks. 
>  
>  
>  
> From: Yuhong Bao [mailto:[email-masked]] 
> Sent: Thursday, November 10, 2011 11:34 PM 
> To: Eric Lawrence 
> Subject: MSDN Blogs: Contact request: A request to the SChannel team 
>  
>  
>  
> Subject: A request to the SChannel team 
>  
>  
>  
> Can you ask the Windows SChannel team to push out an update on Windows  
> Update to Win7/Server2008R2 that fixes the following problems: -  
> Incorrect version checking on the premaster secret -  
> http://www.ietf.org/mail-archive/web/tls/current/msg08139.html - Have  
> the TCP RST response properly cause fallback to TLS 1.0 -  
> http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx  
> And maybe enable TLS 1.1 and 1.2 by default on the server side. 
>  
> This contact request was sent from MSDN Blogs<http://blogs.msdn.com> by  
> Yuhong Bao without sharing your email address.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Nov 2011 23:07:52 +0100 (MET)

Yuhong Bao wrote:
> 
> But the incorrect version checking on the premaster secret is definitely
> a bug, and I am CCing the TLS mailing list as they were encountering
> trouble with it.
>
> > It's not quite correct to call TCP RST fallback "proper" since the  
> > SChannel, and it's something we're looking at. 

Since you brought it up again, I became curious and looked at
the handshake with Wireshark to determine the *REAL* situation.

There seem to be several Bugs in Win7 SChannel and the WinINET fallback
logic.

According to my wireshark trace, when I use MSIE on Win7 with
TLSv1.1 and TLSv1.2 enabled to connect a Server, Win7 will
send a ClientHello with protocol_version { 0x03, 0x03 }
at the SSL record layer in addition to { 0x03, 0x03 }
in the client_version field of the ClientHello handshake
message.

Now that is an obviously stupid idea to tag the first TLS Record
as a TLSv1.2 PDU, when you desire a negotiation of an earlier
TLS version number, because that may preclude a perfectly correct
and sensible implementations of earlier an TLS protocol version
to even look at the contents (ClientHello) of that TLSv1.2 PDU (TLS Record)
and abort with a fatal protocol version alert instead.

The only reasonable behaviour for the TLS client, with respect to the
*original* SSL/TLS protocol design, is to use the lowest protocol
version that the client is willing to use on all of the SSL records
that convey the initial ClientHello handshake message of a new connection.
(but I should point out that fragmenting TLS handshake messages
 would likely cause interop problems with a significant fraction
 of the installed base and is discouraged, so there is typically just
 one initial SSL record with the entire ClientHello handshake
 message on a new connection).

The TCP RST on the socket is the result of the perfectly
valid server behaviour to close the socket of a fatally failed
TLS handshake without lingering.  That is a pretty normal
act of self-defense and resource conservation that every
*sensible* server implementation will be using.  Unless
the connection is in a "good" state, a server can not be
expected to linger on it when it disposes associated resources,
that would just increase the DoS attack surface by factors
at zero value.

-Martin