Re: [TLS] MITM attack on delayed TLS-client auth through renegotiation
Nicolas Williams <Nicolas.Williams@sun.com> Wed, 04 November 2009 22:43 UTC
Return-Path: <Nicolas.Williams@sun.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 88D8628C156 for <tls@core3.amsl.com>; Wed, 4 Nov 2009 14:43:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.045
X-Spam-Level:
X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 vFEah5nqbIqb for <tls@core3.amsl.com>; Wed, 4 Nov 2009 14:43:50 -0800 (PST)
Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id AFA7A28C149 for <tls@ietf.org>; Wed, 4 Nov 2009 14:43:50 -0800 (PST)
Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA4MiCCd013009 for <tls@ietf.org>; Wed, 4 Nov 2009 22:44:12 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id nA4MiBWh011253 for <tls@ietf.org>; Wed, 4 Nov 2009 15:44:11 -0700 (MST)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id nA4MWgd7008654; Wed, 4 Nov 2009 16:32:42 -0600 (CST)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id nA4MWgPh008653; Wed, 4 Nov 2009 16:32:42 -0600 (CST)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Wed, 04 Nov 2009 16:32:42 -0600
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: mrex@sap.com
Message-ID: <20091104223242.GL1105@Sun.COM>
References: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp>
User-Agent: Mutt/1.5.7i
Cc: tls@ietf.org
Subject: Re: [TLS] MITM attack on delayed TLS-client auth through renegotiation
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: Wed, 04 Nov 2009 22:43:52 -0000
Martin, You're right, of course, but this attack is easily defeated by the client checking that the server certificate is the same for the outer TLS connection as for the inner one. It's also easily defeated by the server sending a ChangeCipherSpec in the re-negotiation: the MITM will not be able to decrypt or tamper with the record layer for the inner connection (and if the MITM pretends to the client to be the server end of the inner connection then it will not be able to authenticate as the client to the real server). But suppose the MITM can get the client to accept an TLS_DH_anon_* cipher suite for the outer connection: then there's no way for the client to ensure that the server end-points of the two connections are the same. The best way to defeat this now then is to have the server *always* send a ChangeCipherSpec in the re-negotiation. Re-negotiation handshakes are tunneled in the record layer of a previous TLS connection, and the only links between the two connections (inner and outer) are the authentication credentials of the two end-points. Usually the client end-point will be anonymous in the outer connection, and not anonymous in the inner one. And usually the server certificate must be the same in both cases. Checking that the latter is the case and/or sending a ChangeCipherSpec in the re-negotiation, is and should be sufficient; it should also be required. Another solution would be to use bind the outer connection into the inner connection's PRF, so as to ensure that the Finished messages can only check out if both end-points of the inner connection are also the same end-points for the outer connection. This is what we call channel binding. The additional PRF inputs extension would provide the necessary channel binding facility. In general I prefer the channel binding approach because it's easier to make it work in all cases. Anon-anon cipher-suites? No problem. Note that there is a security consideration here for the TLS channel bindings then, particularly tls-unique: if the inner and outer channels are not bound somehow (either by having the same server end-point cert, or by channel binding of the inner to the outer) then we should want the TLS channel binding see by the application to be that of the of the inner channel, _and_ we should want the inner channel's negotiation to have included a ChangeCipherSpec. Thanks for bringing this to light. Nico --
- [TLS] MITM attack on delayed TLS-client auth thro… Martin Rex
- Re: [TLS] MITM attack on delayed TLS-client auth … Marsh Ray
- Re: [TLS] MITM attack on delayed TLS-client auth … Nicolas Williams