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

Karthik Bhargavan <> Wed, 05 March 2014 13:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC9A31A0450 for <>; Wed, 5 Mar 2014 05:09:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GYs8ebqwuZqZ for <>; Wed, 5 Mar 2014 05:09:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c03::236]) by (Postfix) with ESMTP id 5C8C71A006B for <>; Wed, 5 Mar 2014 05:09:45 -0800 (PST)
Received: by with SMTP id id10so984686vcb.13 for <>; Wed, 05 Mar 2014 05:09:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id s2mr95891vcf.43.1394024981686; Wed, 05 Mar 2014 05:09:41 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Mar 2014 05:09:20 -0800 (PST)
In-Reply-To: <5316A363.3000801@Vimino.COM>
References: <> <> <> <> <5316A363.3000801@Vimino.COM>
From: Karthik Bhargavan <>
Date: Wed, 5 Mar 2014 14:09:20 +0100
Message-ID: <>
Content-Type: multipart/alternative; boundary=001a11c1e7fcd76e9a04f3dbbb23
X-Mailman-Approved-At: Wed, 05 Mar 2014 05:11:37 -0800
Subject: Re: [TLS] MITM Attacks on Client Authentication after Resumption
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


On Wed, Mar 5, 2014 at 5:09 AM, Xuelei Fan <> 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 <>
>>> 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