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

Dr Stephen Henson <> Mon, 03 March 2014 16:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E355F1A01F0 for <>; Mon, 3 Mar 2014 08:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HK_NAME_DR=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9o1NAiRRAZoh for <>; Mon, 3 Mar 2014 08:36:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C6E521A01D9 for <>; Mon, 3 Mar 2014 08:36:55 -0800 (PST)
Received: from ([]:23794 helo=[]) by ( []:10465) with esmtpa (authdaemon_plain:drh) id 1WKVrC-0002qR-99 for (return-path <>); Mon, 03 Mar 2014 16:36:46 +0000
Message-ID: <>
Date: Mon, 03 Mar 2014 16:36:43 +0000
From: Dr Stephen Henson <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
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: Mon, 03 Mar 2014 16:36:58 -0000

On 03/03/2014 15:20, Karthikeyan Bhargavan wrote:
> We are going to present some new man-in-the-middle attacks on TLS
> applications in Tuesday’s working group meeting. These attacks were
> found as part of our research on trying to prove cryptographic
> security for a TLS implementation [1].  We presenting some of the
> materials here to kick-start some discussion and get early comments on
> our proposed countermeasure. Some people on the list already know of
> these attacks but this is the first public disclosure.
> More details are at [2]

I'll just repeat an observation I made at the time. I'm assuming this is still

If the client verifies certificate chains whenever they are presented[1] the
attacker needs a certificate and corresponding private key the client trusts,
typically from a public CA. If not the client will typically reject the
certificate and abort the handshake immediately.

Assuming due diligence by the CA anyone detecting the attack will know the
identity of the attacker or more accurately the identity presented to and
checked by the CA.

If the client checks the hostname against the certificate whenever a
certificate is presented[2] then additionally the attacker needs a certificate
with the same hostname as the attacked server.

1. As opposed to letting everything through and verifying chains after the
handshake is complete. Not something I'd consider wise...
2. This isn't always the case. Some applications check the hostname only after
the handshake has completed.
Dr Stephen N. Henson.
Core developer of the   OpenSSL project:
Freelance consultant see:
Email:, PGP key: via homepage.