[TLS] TLS renegotiation issue

Eric Rescorla <ekr@rtfm.com> Thu, 05 November 2009 03:26 UTC

Return-Path: <ekr@rtfm.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 DB05F28C0E9 for <tls@core3.amsl.com>; Wed, 4 Nov 2009 19:26:53 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Gbe5sWsrYl8A for <tls@core3.amsl.com>; Wed, 4 Nov 2009 19:26:52 -0800 (PST)
Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id D11633A67D7 for <tls@ietf.org>; Wed, 4 Nov 2009 19:26:52 -0800 (PST)
Received: by pzk42 with SMTP id 42so6024382pzk.31 for <tls@ietf.org>; Wed, 04 Nov 2009 19:27:12 -0800 (PST)
Received: by 10.114.187.20 with SMTP id k20mr1492316waf.213.1257391631794; Wed, 04 Nov 2009 19:27:11 -0800 (PST)
Received: from ?10.78.249.58? ([166.205.133.87]) by mx.google.com with ESMTPS id 23sm185479pxi.5.2009.11.04.19.27.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 19:27:11 -0800 (PST)
Message-Id: <73843DF9-EFCB-4B8D-913E-FE2235E5BDD3@rtfm.com>
From: Eric Rescorla <ekr@rtfm.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=Apple-Mail-4--88454205
Content-Transfer-Encoding: 7bit
X-Mailer: iPhone Mail (7C144)
Mime-Version: 1.0 (iPhone Mail 7C144)
Date: Wed, 4 Nov 2009 19:26:59 -0800
Subject: [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 03:26:53 -0000

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.

The attacker doesn't get to directly see any of the client's plaintext
messages but could potentially:

- Issue commands which would then piggyback on subsequent  
authentications
  by the client, including certificate-based authentication.
- Potentially get access to data sent by the client by issuing
  an earlier command which causes the application layer (e.g., HTTP)
  to send the client's traffic to the server.

Marsh Ray, the initial discoverer, has been working with a bunch of
people in the security community to deal with this issue and develop
a fix. Tomorrow AM I'll be posting an initial draft that describes
the obvious fix, which is to cryptographically bind negotiations
to any enclosing connection (if any). I won't be in Hiroshima but
I expect the WG will want to discuss this topic.

-Ekr