IETF Logo Mail Archive

Re: [TLS] TLS renegotiation issue

Florian Weimer <fweimer@bfk.de> Thu, 05 November 2009 19:09 UTC

Return-Path: <fweimer@bfk.de>
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 6AFD13A68C3 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 11:09:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.035
X-Spam-Level:
X-Spam-Status: No, score=-2.035 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 tjL8Y1SJ4Vzd for <tls@core3.amsl.com>; Thu, 5 Nov 2009 11:09:35 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 1C0AB3A69DE for <tls@ietf.org>; Thu, 5 Nov 2009 11:09:31 -0800 (PST)
Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1N67iP-0001bd-Jp; Thu, 05 Nov 2009 20:09:49 +0100
Received: by bfk.de with local id 1N67iP-0003uk-GI; Thu, 05 Nov 2009 19:09:49 +0000
To: Michael D'Errico <mike-list@pobox.com>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <054CC553-7D2E-435E-ADE3-4FBE7B2DB3F8@rtfm.com> <4AF24942.2090809@extendedsubset.com> <4AF31E77.4010602@pobox.com>
From: Florian Weimer <fweimer@bfk.de>
Date: Thu, 05 Nov 2009 19:09:49 +0000
In-Reply-To: <4AF31E77.4010602@pobox.com> (Michael D'Errico's message of "Thu\, 05 Nov 2009 10\:50\:31 -0800")
Message-ID: <82skcspz42.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS renegotiation 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: Thu, 05 Nov 2009 19:09:36 -0000

* Michael D'Errico:

> Excerpt from the PDF:
>
>> char *req =
>>   "GET /highsecurity/index.html HTTP/1.1\r\n"
>>   "Host: example.com\r\n"
>>   "Connection: keep-alive\r\n"
>>   "\r\n"
>>   "GET /evil/doEvil.php?evilStuff=here HTTP/1.1\r\n"
>>   "Host: example.com\r\n"
>>   "Connection: close\r\n"
>>   "X-ignore-what-comes-next: ";
>
> The attack works because the last line is unterminated to effectively
> comment out the client's GET request.
>
> A possible counter to this attack is for the client to send two
> CRLF's prior to its actual request.  This will separate the evil
> request from the actual one containing the Cookie.

It's very hard to tell if this plugs the vulnerability in all cases.
I've written web applications which use an server-internal atemporal
request to access future authentication information.  While that might
seem naive in retrospect, it was the recommended way of adding client
certificate authentication without introducing additional round-trips,
so I'm probably not the only one who did that.  These applications
will likely remain vulnerable if you confine splicing to HTTP request
message boundaries.

-- 
Florian Weimer                <fweimer@bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

v2.23.0 | Report a Bug | By Email