Re: [TLS] A request to the SChannel team

Martin Rex <mrex@sap.com> Fri, 11 November 2011 22:08 UTC

From: Martin Rex <mrex@sap.com>
Message-Id: <201111112207.pABM7qAQ014491@fs4113.wdf.sap.corp>
To: yuhongbao_386@hotmail.com
Date: Fri, 11 Nov 2011 23:07:52 +0100
In-Reply-To: <SNT125-W387C073FA673D3A42AA0D3C3DD0@phx.gbl> from "Yuhong Bao" at Nov 11, 11 09:11:22 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Cc: tls@ietf.org, ericlaw@exchange.microsoft.com
Subject: Re: [TLS] A request to the SChannel team
Precedence: list
Reply-To: mrex@sap.com

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.
>
> > From: ericlaw@exchange.microsoft.com 
> >  
> > 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. 

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

Re: [TLS] A request to the SChannel team Yuhong Bao
Re: [TLS] A request to the SChannel team Martin Rex