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

Dr Stephen Henson <lists@drh-consultancy.co.uk> Tue, 04 March 2014 16:05 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 D07F31A01A8 for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 08:05:50 -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 N5OQ_cKSZLFR for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 08:05:49 -0800 (PST)
Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id BBCB31A00F5 for <tls@ietf.org>; Tue, 4 Mar 2014 08:05:22 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:45878 helo=[192.168.7.9]) by relay11.mail.eu.clara.net (relay.clara.net [81.171.239.31]:10465) with esmtpa (authdaemon_plain:drh) id 1WKrqI-0005Fc-3Z (return-path <lists@drh-consultancy.co.uk>); Tue, 04 Mar 2014 16:05:18 +0000
Message-ID: <5315F9BA.4060805@drh-consultancy.co.uk>
Date: Tue, 04 Mar 2014 16:05:14 +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: Martin Thomson <martin.thomson@gmail.com>
References: <20140303193737.2A2251AC36@ld9781.wdf.sap.corp> <5315DD23.30901@drh-consultancy.co.uk> <CABkgnnVYj-2BKwMLTgH-hVxSSGncoppOv-gZhbdBQB=QCBB-Ew@mail.gmail.com>
In-Reply-To: <CABkgnnVYj-2BKwMLTgH-hVxSSGncoppOv-gZhbdBQB=QCBB-Ew@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sR4T8Shts_e1dk-STBgKTbf5dtE
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 16:05:51 -0000

On 04/03/2014 15:23, Martin Thomson wrote:
> On 4 March 2014 14:03, Dr Stephen Henson <lists@drh-consultancy.co.uk> 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 "foo.example.com", but as long as you have "*.example.com"
> or "bar.example.com" in subjectAltName, you will proceed with requests
> to "bar.example.com" 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
> name.
> 

Well in the specific case of OpenSSL a hostname is supplied via the API and that
is checked against the server certificate whenever it is presented. So it would
allow the certificate to change but an attacker would need a trusted certificate
matching the server's hostname. If they have that they can MITM the server
(provided it doesn't support client authentication) anyway.

It has been suggested that clients could be stricter and prohibit changes of
server certificate during renegotiation entirely, if not outright at least by
default.

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.

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.