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

Dr Stephen Henson <lists@drh-consultancy.co.uk> Tue, 04 March 2014 14:03 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 1414B1A0176 for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 06:03:28 -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 hb0B3pSOCrn6 for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 06:03:25 -0800 (PST)
Received: from claranet-outbound-smtp06.uk.clara.net (claranet-outbound-smtp06.uk.clara.net [195.8.89.39]) by ietfa.amsl.com (Postfix) with ESMTP id AFE421A0206 for <tls@ietf.org>; Tue, 4 Mar 2014 06:03:24 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:50437 helo=[192.168.7.9]) by relay16.mail.eu.clara.net (relay.clara.net [81.171.239.36]:10465) with esmtpa (authdaemon_plain:drh) id 1WKpwF-0001dX-MZ for tls@ietf.org (return-path <lists@drh-consultancy.co.uk>); Tue, 04 Mar 2014 14:03:20 +0000
Message-ID: <5315DD23.30901@drh-consultancy.co.uk>
Date: Tue, 04 Mar 2014 14:03:15 +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: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp>
In-Reply-To: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zm-tWplZrQd3V5QcDlwybTJe0b8
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 14:03:28 -0000

On 03/03/2014 19:37, Martin Rex wrote:
> Dr Stephen Henson wrote:
>>
>> 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.
>>
>> 2. This isn't always the case. Some applications check the hostname only after
>> the handshake has completed.
> 
> An application client that is using a TLS library _without_ callbacks,
> and requests a blocking TLS handshake to be performed, will only get to
> see the server certificate after the handshake has completed.
> 
> While the X.509 cert chain validation might be performed in-band
> by the TLS stack, the rfc2818 Section 3.1 server endpoint
> identification is left up to the application caller.
> 

A stack might have an option to check the hostname as part of the in-band cert
validation and, on failure, abort the handshake at that point just like any
other validation error.

For example OpenSSL 1.0.2 can do that but previous versions do not. Since that's
an unreleased version it's likely no existing clients use that option.

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.

Steve.
-- 
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.