Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3

Martin Rex <mrex@sap.com> Fri, 13 November 2009 18:36 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 417C93A6949 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 10:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.171
X-Spam-Level:
X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx4MInTskj4J for <tls@core3.amsl.com>; Fri, 13 Nov 2009 10:36:46 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id D10143A68B5 for <tls@ietf.org>; Fri, 13 Nov 2009 10:36:45 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nADIb6xF013134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Nov 2009 19:37:06 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911131837.nADIb6GY000472@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Fri, 13 Nov 2009 19:37:06 +0100
In-Reply-To: <4AFB2B42.9060602@extendedsubset.com> from "Marsh Ray" at Nov 11, 9 03:23:14 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLSrenego - possibilities, suggestion for SSLv3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 18:36:47 -0000

Marsh Ray wrote:
> 
> Well, if the remote endpoint allows you to initiate a renegotiation. MS
> IIS for example responds with a TCP RST, other implementations may be
> less direct.

>From what Nico said in earlier messages about the Programming Model
for Microsoft's TLS implementation (schannel SSP), the code above
SSPI must know an implement a lot of TLS message flow.

According to that sketch, performing a TLS handshake requires a significant
amount of code above SSPI, and performing a TLS renegotiation requires
an awful huge amount of code above SSPI.  I have never used schannel
myself (and haven't found programming examples yet), but it seems
that the app on top of SSPI _must_ know whether incoming data is
application data, protected application data or handshake messages
and pass each of them to distinct SSPI calls or get an error.
The return calls of those SSPI functions probably indicate which
call to do next (or which kind of data to expect next).

So an app on top of SSPI using the schannel SSP might not expect
the client to request rekeying at arbitrary times during communication
and that unexpected (protected) ClientHello handshake message is then
passed to a Message-unprotection call of SSPI where it is rejected.
When that happens, the server seems to terminate the session
(delete the security context) and close the socket/connection,
which might be the reason why you receive a TCP RST.


Nico also mentioned, that with SSPI, the renegotiation context
uses a different/seperate context handle that the original context.

Which seems to imply, that for a TLS renegotiation by the app on top
of SSPI, the app has to call the message protection/unprotection
calls of the previous context for the initial handshake messages
of the new context -- until the Interator Function(s) indicate
that this is no longer necessary (because ChangeCipherSpec has
been sent).

If TLS renegotiation actually works like this in SSPI, then
an SSPI app is actually playing the MITM-Attack every time
that it renegotiates (i.e. it would perform the MITM-Attack on
its own TLS stack).

-Martin