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

Martin Thomson <> Tue, 04 March 2014 15:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 25AB51A0085 for <>; Tue, 4 Mar 2014 07:23:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RPSkki9pgfCJ for <>; Tue, 4 Mar 2014 07:23:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) by (Postfix) with ESMTP id 6EC151A007C for <>; Tue, 4 Mar 2014 07:23:45 -0800 (PST)
Received: by with SMTP id q58so4976566wes.26 for <>; Tue, 04 Mar 2014 07:23:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjHdu+OQGHuNk7NckAHC1sweg/X9LYANj6yZ2suOLBw=; b=0BqlbN0jHmQvMXy+XhM4ER1CYMgYaYAZX/pJEIxUlyQLuzxLpv7d2qtLlQoe9Xti/I ZX15SWEf0pKeROYiNulb+RExQWLJgNu87S5EUkTNYK0eJql3zqE30RwDp2moiff0hOiO 6pmMapw2IrMYYxJFvAT0rgbMkJlReDUlM9tMAW3ONlhQRWWJKTZg4kxkaI2xVMUyV3eu Spp7N8Zp9MrjwYxke6f52Vw48dvmNaElV9tmje89ysHlBQiUMqdS3AjNQqM9jKho3Xs2 b0NBM1EVABzwL7neIGiaht0X8RqQU6xnJEu3jdtxTptntarzEJiNBfInh37Vk2DDYmnM 0s6w==
MIME-Version: 1.0
X-Received: by with SMTP id an7mr14522wjc.39.1393946621776; Tue, 04 Mar 2014 07:23:41 -0800 (PST)
Received: by with HTTP; Tue, 4 Mar 2014 07:23:41 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 4 Mar 2014 15:23:41 +0000
Message-ID: <>
From: Martin Thomson <>
To: Dr Stephen Henson <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Mar 2014 15:23:47 -0000

On 4 March 2014 14:03, Dr Stephen Henson <> wrote:
> I performed a few checks with an experimental option to change the server
> certificate during renegotiation, which I believe simulates the attack
> mechanism. If the client checks certificates in band then all versions choke
> with a verification error if a chain is untrusted. For 1.0.2 only it also chokes
> if the chain is trusted but the hostname doesn't match.

This is an interesting option.  I like the general idea, but wonder
what "hostname doesn't match" means in this case.

To provide some context, in HTTP/2 we are considering having multiple
names share the same connection, as long as they are covered by
wildcards or additional subjectAltName values.  You might start out
looking for "", but as long as you have "*"
or "" in subjectAltName, you will proceed with requests
to "" on that connection.

I think that it would be unlikely that a renegotiated certificate
would include some names from a previous certificate, but not others,
but that might be a problem if an implementation fixates on a single