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

Dr Stephen Henson <lists@drh-consultancy.co.uk> Mon, 03 March 2014 16:36 UTC

Return-Path: <lists@drh-consultancy.co.uk>
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 E355F1A01F0 for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.111
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o1NAiRRAZoh for <tls@ietfa.amsl.com>; Mon, 3 Mar 2014 08:36:55 -0800 (PST)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id C6E521A01D9 for <tls@ietf.org>; Mon, 3 Mar 2014 08:36:55 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:23794 helo=[192.168.7.9]) by relay12.mail.eu.clara.net (relay.clara.net [81.171.239.32]:10465) with esmtpa (authdaemon_plain:drh) id 1WKVrC-0002qR-99 for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Mon, 03 Mar 2014 16:36:46 +0000
Message-ID: <5314AF9B.8000402@drh-consultancy.co.uk>
Date: Mon, 03 Mar 2014 16:36:43 +0000
From: Dr Stephen Henson <lists@drh-consultancy.co.uk>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: tls@ietf.org
References: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@inria.fr>
In-Reply-To: <BB2FE60E-A7CA-4EA7-BFC8-AB794EC6FF00@inria.fr>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/43vMgEIwwhSwQ3b8tyf-HZ5_D60
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: 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 https://secure-resumption.com [2]
> 

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

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.

Steve.
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: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.