IETF Logo Mail Archive

Re: [TLS] MITM Attacks on Client Authentication after Resumption

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 04 March 2014 20:17 UTC

Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D341A028C for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 12:17:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLmkbdW-5zib for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 12:16:59 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 806781A01C1 for <tls@ietf.org>; Tue, 4 Mar 2014 12:16:59 -0800 (PST)
Received: from [31.133.167.72] (dhcp-a748.meeting.ietf.org [31.133.167.72]) by che.mayfirst.org (Postfix) with ESMTPSA id A297AF984; Tue, 4 Mar 2014 15:16:53 -0500 (EST)
Message-ID: <531634B2.8050004@fifthhorseman.net>
Date: Tue, 04 Mar 2014 20:16:50 +0000
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0
MIME-Version: 1.0
To: Adam Langley <agl@google.com>, Dr Stephen Henson <lists@drh-consultancy.co.uk>
References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <CABkgnnVYj-2BKwMLTgH-hVxSSGncoppOv-gZhbdBQB=QCBB-Ew@mail.gmail.com> <5315F9BA.4060805@drh-consultancy.co.uk> <CAL9PXLy4KM_bqS3biRqOMsZ7j+mA6uu75GqJVmBF9wC98_3aQA@mail.gmail.com>
In-Reply-To: <CAL9PXLy4KM_bqS3biRqOMsZ7j+mA6uu75GqJVmBF9wC98_3aQA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="x6oD1K0vQfWnbIgp4gHcrHF0897Td5IdD"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1OZSZfYerfnkVDOMzGsJRAKGrwc
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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/options/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: Tue, 04 Mar 2014 20:17:04 -0000

On 03/04/2014 04:11 PM, Adam Langley wrote:
> On Tue, Mar 4, 2014 at 11:05 AM, Dr Stephen Henson
> <lists@drh-consultancy.co.uk> wrote:
>> I'd be interested if anyone knows of examples where the server certificate does
>> have to change during renegotiation and how common that practice is.
> 
> Chrome outright rejects renegotiations where the leaf certificate
> changes and we've had no reported issues.

If a client currently doesn't want to leak SNI to a passive attacker and
is willing to burn roundtrips, it can make a non-SNI TLS handshake to
the server (accepting whatever certificate is given) and then
immediately trigger renegotiation with the SNI header.

tstclnt (from mozilla's NSS) has command line options to offer different
SNI values at renegotiation.

If chrome doesn't do this, it's reasonable for it to reject changed EE
certs on renegotiation.  But that doesn't rule out this use case.

	--dkg

v2.23.0 | Report a Bug | By Email