Re: [TLS] TLS or HTTP issue?
Martin Rex <mrex@sap.com> Fri, 06 November 2009 17:13 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 1759528C179 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 09:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.057
X-Spam-Level:
X-Spam-Status: No, score=-6.057 tagged_above=-999 required=5 tests=[AWL=0.192, 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 1aSj1cHBltK2 for <tls@core3.amsl.com>; Fri, 6 Nov 2009 09:13:24 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A4FC028C177 for <tls@ietf.org>; Fri, 6 Nov 2009 09:13:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA6HDjT3020102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Nov 2009 18:13:45 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911061713.nA6HDi2n021935@fs4113.wdf.sap.corp>
To: Bruno.Harbulot@manchester.ac.uk
Date: Fri, 06 Nov 2009 18:13:44 +0100
In-Reply-To: <4AF444EE.9070401@manchester.ac.uk> from "Bruno Harbulot" at Nov 6, 9 03:46:54 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: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] TLS or HTTP issue?
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, 06 Nov 2009 17:13:25 -0000
Bruno Harbulot wrote: > > > > > 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. The ramification are amplificated by the HTTP 1.1 Connection:keep-alive that allows pipelining of requests and results in asynchronous processing of requests and replys. For re-negotiations, the following requirement from rfc5246 6.2.1. Fragmentation (last paragraph): Note: Data of different TLS record layer content types MAY be interleaved. Application data is generally of lower precedence for transmission than other content types. However, records MUST be delivered to the network in the same order as they are protected by the record layer. Recipients MUST receive and process interleaved application layer traffic during handshakes subsequent to the first one on a connection. Provides and interesting additional challenge, and documents that at least some of the original protocol designers didn't sufficiently reflect on the implications. Similarly rfc-5246, 7.4.1.1. Hello Request Since handshake messages are intended to have transmission precedence over application data, it is expected that the negotiation will begin before no more than a few records are received from the client. If the server sends a HelloRequest but does not receive a ClientHello in response, it may close the connection with a fatal alert. I think it is underspecified what "interleaved application data and handshake messages" and "handshake message have transmission precedence over application data" is supposed to mean, and what kind of signalling would be necessary between the TLS protocol stack and the application caller in order to convey the underspecified semantics unambiguously. I wasn't remotely aware of the applicability for real world scenarios beyond the command execution I suggested in my description, when I wrote about an MITM attack scenario that had briefly crossed my mind the night before, and for which I had not found any indications in rfc5246 (scanning it for about 20 minutes) that would stop it, before sending off the mail. I had not realized that one could similarly proxy an initial TLS handshake with a client into a renegotiate of the server and things like the request-completion for the basic-auth based or cookie-based authentications. Marshs published research on the issue expanded my thinking about susceptible scenarios significantly. Excellent work, Marsh! -- and thank you for all the research! For the cookie-auth or basic-auth based scenarios depicted by Marsh, the asynchronous processing of pipelined requests creates interesting new opportunities. "Clearing the command cache" might require a significant change in some application protocol stacks. In order to efficientl process requests, and nowadays Connection: keep-alive pipelined requests, there are often intermediate layers for the request parsing that will combine and re-slice what comes out of SSL, so that the application may efficiently process the requests--including URL argument parsing, parsing the MIME-header, parsing certain header fields (Host:,Cookie:,authorization) and potentially code page translations/transformations. When analyzing performance problems reported by a customer 3 years ago I noticed that their Apache reverse proxy (using SSL-reencryption into our backend software) was tearing up the forwarded requests into pieces, forwarding each line of the MIME-header of the request and the empty newline into seperate SSL-records -- slowing down the processing of the request significantly. >From the original design, and in the two quoted paragraphs above, it appears that SSL and its successor TLS was intended to be _very_ transparent, and the spec contains guidance for security-relevant signaling to the application only for the initial TLS handshake on a connection (full initial handshake, and session resume), but _NOT_ for the session renegotiation. Therefore, I think, we do have a real shortcoming of the SSL/TLS protocol, and we really should scramble to fix it. That includes improving on the guidance for the signaling and semantics of a TLS session renegotiate of the TLS protocol stack to the application -- in a fashion so that it can be folded back into rfc5246bis. -Martin
- [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