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

Karthik Bhargavan <karthik.bhargavan@gmail.com> Wed, 05 March 2014 13:09 UTC

Return-Path: <karthik.bhargavan@gmail.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 EC9A31A0450 for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 05:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 GYs8ebqwuZqZ for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 05:09:45 -0800 (PST)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8C71A006B for <tls@ietf.org>; Wed, 5 Mar 2014 05:09:45 -0800 (PST)
Received: by mail-vc0-f182.google.com with SMTP id id10so984686vcb.13 for <tls@ietf.org>; Wed, 05 Mar 2014 05:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=J52s7TVA/u54ihzCpIgdjUcebcW3p3NJhQunnyzKZsQ=; b=aeCWooKGEhRSgXskkQGCvKqqPDUHHSsP7w5fK6hdimt8ObCoF2O4r62WSWQ3p2R9Ht icEU9YnR6LQPBezMdbrmJ9VqKoZZ732BYdc+QmXX5k3Af4BQk0QyfAREszHtxWK2p8Ly pC5EnEa7m1GTTfFMAU9QkgUmslNyN7KU3TpBysbT+joCwcLehEvs3fG2C8XoevzVQcW6 YNFlC9FHc/0OzOTXnlRZhe5UOpHsZsLqhrYEDUNzEfUM3MXCz5rHextERinN60UBiDS2 TPlVoKfbZ44v5CNwVu/1UgCOE7WI6VaRfbxULdTBY1qjFgQ1qddPbUrl8qZLE+3BZSLz awJw==
X-Received: by 10.220.48.194 with SMTP id s2mr95891vcf.43.1394024981686; Wed, 05 Mar 2014 05:09:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.96.195 with HTTP; Wed, 5 Mar 2014 05:09:20 -0800 (PST)
In-Reply-To: <5316A363.3000801@Vimino.COM>
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> <5316A363.3000801@Vimino.COM>
From: Karthik Bhargavan <karthik.bhargavan@gmail.com>
Date: Wed, 5 Mar 2014 14:09:20 +0100
Message-ID: <CA+_8ft7cckoO_YGncQ89NmdoVcSUNiLO1pPJbu=UAJRUnB9aGA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1e7fcd76e9a04f3dbbb23
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Mm2lGQ7oOaOQwvES-cmGThgDFww
X-Mailman-Approved-At: Wed, 05 Mar 2014 05:11:37 -0800
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 13:10:32 -0000

After my talk at the meeting, its worth summarizing comments on the triple
handshake attack and its impact on client-authenticated TLS renegotiation.

In the common case (e.g HTTPS) where a server presents  a certificate in
both the initial handshake and during renegotiation, it would be enough for
the client to verify that the certificate doesn't change. (More precisely,
the client needs to verify that the principals represented by both
certificates are equally trustworthy.)

There are other cases, and I'd be curious to know how common they are, when
one or both handshakes does not have a server certificate. These would be
more difficult to fix with a general TLS library-level policy.

Typical examples (from discussion at the meeting):

- Initial handshake uses DH_anon or a self-signed server cert
  and renegotiation uses the real server certificate

- Initial handshake uses a server certificate,
  and renegotiation uses PSK or SRP to authenticate the user

In the first case, I guess the purpose is to protect the server name from
passive attackers. In the second, the purpose is privacy for the user's
SRP/PSK identity.

In both cases, if both handshakes happen on the same connection, RFC5746
(renego indication) gives us a pretty strong guarantee that the principals
on both ends do not change. In effect, the second handshake retroactively
authenticates the first.

The triple handshake attack shows that this nice guarantee does not hold if
there is session resumption between the two handshakes.

I can't think of easy implementation-level ways of fixing the DH_anon and
PSK/SRP cases.

Best,
Karthik



On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan <xuelei.fan@vimino.com> wrote:

> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>