IETF Logo Mail Archive

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

Xuelei Fan <xuelei.fan@vimino.com> Wed, 05 March 2014 04:09 UTC

Return-Path: <xuelei.fan@vimino.com>
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 E893A1A020C for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 20:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 tU8h7FdgQTqc for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 20:09:25 -0800 (PST)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com [209.85.192.182]) by ietfa.amsl.com (Postfix) with ESMTP id 896EF1A0200 for <tls@ietf.org>; Tue, 4 Mar 2014 20:09:25 -0800 (PST)
Received: by mail-pd0-f182.google.com with SMTP id g10so497606pdj.13 for <tls@ietf.org>; Tue, 04 Mar 2014 20:09:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9bXeMebKgEyXGXLdF1VkTh7FcFdxIj8Hz9INcgvqjh0=; b=f1J3VDZ7RkNWyRdYTtwNfkr7K/8erPvf/tKoyqvHhQe7OXvrMlUasJIKcxuOa0XRv2 wZCCRh2WXTqMC3lhxIKy3vzQNrYf3+/cBQsxfiwRX/T/rNZQd6uec3FUSdeuDJmewwWC rV/HuAGz1uacQ76k/4V3TUU7WEkQkbGov0H2a+bVd7Wmi0EUOjYQYbnFddMhPSJN48CF FhNmJvGUaKhmPbIdHXzcsaUCmeJcnpj59TaFx9GiC3zlHvsl38XVY7MtkH4NeXaKM2Ge qhtXi+5c7WDR88QtL5tcwQsvRC3kfQ0NIx7J1/zaYw2tx02D5tl8QsdP2sBNca+pKqNm r6zg==
X-Gm-Message-State: ALoCoQkgfr0HqBcTl7oqZRKuAJlVxRuPd7JzBCFlCGfKOXCX69TmrgQ1Y6NhqaUgom3EUejOsx2Q
X-Received: by 10.67.1.202 with SMTP id bi10mr4185396pad.68.1393992562196; Tue, 04 Mar 2014 20:09:22 -0800 (PST)
Received: from [192.168.1.105] ([114.245.173.86]) by mx.google.com with ESMTPSA id ei4sm2777250pbb.42.2014.03.04.20.09.19 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 20:09:21 -0800 (PST)
Message-ID: <5316A363.3000801@Vimino.COM>
Date: Wed, 05 Mar 2014 12:09:07 +0800
From: Xuelei Fan <xuelei.fan@vimino.com>
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> <5315DD23.30901@drh-consultancy.co.uk> <CABkgnnVYj-2BKwMLTgH-hVxSSGncoppOv-gZhbdBQB=QCBB-Ew@mail.gmail.com> <5315F9BA.4060805@drh-consultancy.co.uk>
In-Reply-To: <5315F9BA.4060805@drh-consultancy.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jf4b6wVNv-74Rf0oE_psY_sCDUo
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: Wed, 05 Mar 2014 04:09:28 -0000

On 3/5/2014 12:05 AM, Dr Stephen Henson wrote:
> 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.
>>
JSSE enabled the hostname checking during handshaking for HTTPS and 
LDAP.  If hostname doesn't match, the handshaking is terminated immediately.

> 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.
>
I was wondering, if the cipher suite is changed from RSA cert based to 
EC cert based (and vice versa), the server certificate would have to 
change accordingly.  Not sure about the case in practice.

Xuelei

v2.23.0 | Report a Bug | By Email