Re: [TLS] simplistic renego protection

Martin Rex <mrex@sap.com> Fri, 20 November 2009 03:54 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 EC5C93A67B0 for <tls@core3.amsl.com>; Thu, 19 Nov 2009 19:54:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.07
X-Spam-Level:
X-Spam-Status: No, score=-6.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 9HYb2xVHBTGl for <tls@core3.amsl.com>; Thu, 19 Nov 2009 19:54:27 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DAB253A676A for <tls@ietf.org>; Thu, 19 Nov 2009 19:54:26 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAK3sI0d006535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Nov 2009 04:54:18 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911200354.nAK3sHqD011263@fs4113.wdf.sap.corp>
To: nelson@bolyard.me
Date: Fri, 20 Nov 2009 04:54:17 +0100
In-Reply-To: <4B060687.30007@bolyard.me> from "Nelson B Bolyard" at Nov 19, 9 07:01:27 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] simplistic renego protection
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, 20 Nov 2009 03:54:28 -0000

Nelson B Bolyard wrote:
> 
> > If lenient servers are allowed, then I think it will take *much* longer
> > until the vulnerability is eliminated from most connections.
> 
> I must have missed the message wherein "lenient server" was defined.
> Is it a server that accepts client hellos without any signal that the
> client has been upgraded, but merely refuses to renegotiate with such a
> client?
> 
> IOW, is it the kind of server that numerous vendors are shipping now,
> that recent patches to open source have just created, one that refuses to
> renegotiate at all but still accepts old style client hellos?

The type of (old) servers that are going to be with us for
quite some time are those that either never did renegotiate
where it was recently disabled.

Problem is, that they leave the clients in the dark if they don't update.
There is no assurance/confirmation at the protocol level that they
can't be abused.


> 
> Is someone proposing to abolish them already?

I must have missed the widespread availability of patches for
secure renegotiation -- or are they taking down the entire internet
until further notice?   ;-)

> 
> > Remember, rejecting a renegotiating ClientHello does not necessarily lead
> > to an interoperability failure; it only does so if the client will not
> > reconnect.
> 
> By definition, the alert that rejects a renegotiating client auth
> (no_renegotiation) is a warning alert.  It leaves the previous TLS
> connection and session state intact and able to continue.  So IINM, it does
> not lead to an interoperability failure unless the client chooses to treat
> that alert as fatal, despite being a warning, AND refuses to reconnect.
> Right?

In theory "no_renegotiation" alert is a warning alert.

In theory a server that wants to obtain a client certificate
and send a HelloRequest should treat a resulting 'no_renegotiation' alert
similar to a no_certificate alert (SSLv3) or empty Certificate message.

but it is probably not that simple.


If the server chokes when the client denies the HelloRequest
with a no_renegotiation alert and the app on top re-connects,
repeating the request, then this could result in a deadly
embrace.  I hope the app uses a retry-counter.

-Martin