IETF Logo Mail Archive

Re: [TLS] TLS or HTTP issue?

Florian Weimer <fweimer@bfk.de> Fri, 06 November 2009 09:25 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 2160F28C17B for <tls@core3.amsl.com>; Fri, 6 Nov 2009 01:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.062
X-Spam-Level:
X-Spam-Status: No, score=-2.062 tagged_above=-999 required=5 tests=[AWL=0.188, 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 7GOLzkgYWasr for <tls@core3.amsl.com>; Fri, 6 Nov 2009 01:25:50 -0800 (PST)
Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by core3.amsl.com (Postfix) with ESMTP id 2D91E28C175 for <tls@ietf.org>; Fri, 6 Nov 2009 01:25:48 -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 1N6L56-0005i9-1j; Fri, 06 Nov 2009 10:26:08 +0100
Received: by bfk.de with local id 1N6L55-0003ik-OY; Fri, 06 Nov 2009 09:26:07 +0000
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com> <4AF33D07.7040100@gnutls.org>
From: Florian Weimer <fweimer@bfk.de>
Date: Fri, 06 Nov 2009 09:26:07 +0000
In-Reply-To: <4AF33D07.7040100@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu\, 05 Nov 2009 23\:00\:55 +0200")
Message-ID: <82639ongwg.fsf@mid.bfk.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
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 09:25:51 -0000

* Nikos Mavrogiannopoulos:

> I'll become a bit pedantic and note here that this isn't really a TLS
> issue.

I'm not sure.  We've got a middleware which provides RPC services over
TLS with certificates on both ends, and it happens that we're
vulnerable as well[1], even though we require client certificates from
the start.  Suppose that there is an RPC which is some sort of store
operation, allowing reading back the stored data by the client.  The
attacker pre-loads half of such an RFC call, triggers renegotation,
and splices this connection to an unsuspecting client.  The client
will complete the RPC call, the server will save the call contents
(including metadata) as the payload of the store request that precedes
it, associated with the attacker's certificate (because it sticks to
the certificate it saw first).  The attacker can use the service to
read back the saved call contents, gaining access to data it would not
ordinarily have access to.

Theoretically, this attack can be detected by the server, but not
using the APIs that are currently deployed.  You are right that HTTP
is worse, but based on the attack sketched above, the basic issue also
affects other services.

[1] We've got other safeguards which prevent actual exploitation in
our case, but the theoretical vulnerability is still there.

-- 
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