Re: [TLS] TLS or HTTP issue?
Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk> Fri, 06 November 2009 15:47 UTC
Return-Path: <ietf-ietf-tls@m.gmane.org>
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 357253A6852 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 07:47:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 jRjlG0O+TOUz for <tls@core3.amsl.com>; Fri, 6 Nov 2009 07:47:00 -0800 (PST)
Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by core3.amsl.com (Postfix) with ESMTP id D4C523A6991 for <tls@ietf.org>; Fri, 6 Nov 2009 07:46:59 -0800 (PST)
Received: from list by lo.gmane.org with local (Exim 4.50) id 1N6R1w-0004iI-9Q for tls@ietf.org; Fri, 06 Nov 2009 16:47:16 +0100
Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Fri, 06 Nov 2009 16:47:16 +0100
Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Fri, 06 Nov 2009 16:47:16 +0100
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Bruno Harbulot <Bruno.Harbulot@manchester.ac.uk>
Date: Fri, 06 Nov 2009 15:46:54 +0000
Lines: 74
Message-ID: <4AF444EE.9070401@manchester.ac.uk>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: rain.gmane.org
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
In-Reply-To: <4AF33D07.7040100@gnutls.org>
Sender: news <news@ger.gmane.org>
Cc: Eric Rescorla <ekr@rtfm.com>
Subject: Re: [TLS] TLS or HTTP issue?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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, 06 Nov 2009 15:47:01 -0000
Hello, Nikos Mavrogiannopoulos wrote: > Eric Rescorla wrote: >> TLS WG members will want to check out this announcement of a >> new attack on the TLS renegotiation logic. See here: >> >> http://www.extendedsubset.com/ >> >> The high-level summary is that the attacker negotiates TLS with the >> server and then subsequently proxies the client's negotiation *over* >> that channel. This allows the attacker to inject arbitrary content of >> their choice in front of data sent from the TLS client to the TLS >> server. This data will be treated by the server as if it came from the >> client. Once the new handshake has finished, the attacker can't >> do anything else useful. > > I'll become a bit pedantic and note here that this isn't really a TLS > issue. We have an initial server-authenticated only session and some > renegotiation of parameters over it to authenticate the client. However > TLS doesn't guarantee[0] that if the renegotiation is successful > authenticating the client, then the data from the initial session were > also by the same authenticated client. > Think for example a session that it is anonymous (DH). Why one should > assume that commands over the anonymous connection are to be trusted if > a successful renegotiation follows? > > So for me the issue is on HTTP's usage of the TLS protocol > renegotiation. After a TLS renegotiation for authentication the previous > command cache should have been cleared and reissued after negotiation. I think you have a point, I'm not sure if it's HTTP as such that is to blame, rather the assumptions made by the frameworks implementing it. Authentication via client-certificate in HTTPS has always been a bit at odds with the rest of the HTTP authentications schemes. HTTP has status codes for requiring authentication (401), but client-cert authentication doesn't fit well into this model. The need vs. want client-cert feature itself isn't handled particularly well by browsers. Requiring a client-cert (and closing the connection if one isn't presented) can be confusing to the user. I think the problem comes from the fact that SSL/TLS is intended to behave transparently, like normal sockets, for the application using it, whereas this issue is clearly not the case when re-negotiation happens. Perhaps this should just be another special case handled by the application layer (the other special case I have in mind is the way closing the socket behaves slightly differently to normal sockets). This attack could be prevented if the HTTP framework was notified when a renegotiation had happened and thus made aware that the command it just got may not have been made with the same credentials. For example, this wouldn't be an issue if: - the HTTP method sent just before the renegotiation was a safe method (GET/HEAD) - the HTTP application was using safe methods correctly (no GET /page?action=delete for example) - if the HTTP method isn't safe (POST, PUT, ...), then send a 401 status response. The problem here is that a 401 response status requires a challenge header according to the HTTP spec and there isn't one to require a client certificate; this being said, it should be possible to extend HTTP and have 'WWW-Authenticate: Transport' (or something similar) meaning that it's up to TLS to provide the required authentication information. As you said, I also think handling this problem at the TLS level is cleaner since the assumption that TLS sockets behave transparently like normal sockets should still be valid in this case. Best wishes, Bruno.
- [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Florian Weimer
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- [TLS] TLS or HTTP issue? (was: TLS renegotiation … Nikos Mavrogiannopoulos
- Re: [TLS] TLS renegotiation issue Yngve N. Pettersen (Developer Opera Software ASA)
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Cullen Jennings
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Michael Gray
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] TLS or HTTP issue? Bruno Harbulot
- Re: [TLS] TLS renegotiation issue Blumenthal, Uri - 0662 - MITLL
- Re: [TLS] TLS or HTTP issue? Peter Saint-Andre
- Re: [TLS] TLS or HTTP issue? Martin Rex
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nathaniel W Filardo
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Nicolas Williams
- [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Robert Relyea
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Michael D'Errico
- Re: [TLS] TLS or HTTP issue? Dean Anderson
- Re: [TLS] TLS renegotiation issue David Harrington
- [TLS] To API or not (Re: TLS renegotiation issue) Nicolas Williams
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Marsh Ray
- [TLS] Simple way to drop re-negotiation in HTTP (… Nicolas Williams
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Martin Rex
- Re: [TLS] draft-rescorla-tls-renegotiate.txt Martin Rex
- Re: [TLS] Simple way to drop re-negotiation in HT… Marsh Ray
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- Re: [TLS] TLS or HTTP issue? Marsh Ray
- Re: [TLS] TLS renegotiation issue Michael D'Errico
- Re: [TLS] TLS renegotiation issue Marsh Ray
- Re: [TLS] TLS or HTTP issue? Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] Test Server (was TLS renegotiation issu… Michael D'Errico
- Re: [TLS] TLS renegotiation issue Nagendra Modadugu
- Re: [TLS] TLS renegotiation issue Eric Rescorla
- Re: [TLS] TLS or HTTP issue? Nicolas Williams
- Re: [TLS] TLS renegotiation issue Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Florian Weimer
- Re: [TLS] Simple way to drop re-negotiation in HT… Nicolas Williams
- Re: [TLS] TLS or HTTP issue? Chris Newman
- Re: [TLS] TLS or HTTP issue? (was: TLS renegotiat… Chris Newman
- Re: [TLS] TLS renegotiation issue Bodo Moeller
- Re: [TLS] TLS or HTTP issue? Nikos Mavrogiannopoulos
- [TLS] Comments on draft-rescorla-tls-renegotiate Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nicolas Williams
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Nelson B Bolyard
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Bodo Moeller