Re: [TLS] MITM Attacks on Client Authentication after Resumption (Martin Rex) Tue, 04 March 2014 19:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 544ED1A01C1 for <>; Tue, 4 Mar 2014 11:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T-6c1VBf0YRu for <>; Tue, 4 Mar 2014 11:56:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DC4CF1A01B0 for <>; Tue, 4 Mar 2014 11:56:17 -0800 (PST)
Received: from by (26) with ESMTP id s24JuAF4029177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Mar 2014 20:56:10 +0100 (MET)
In-Reply-To: <>
To: Adam Langley <>
Date: Tue, 4 Mar 2014 20:56:10 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: "" <>
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: Tue, 04 Mar 2014 19:56:21 -0000

Adam Langley wrote:
> Dr Stephen Henson <> wrote:
>> 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.
> Chrome outright rejects renegotiations where the leaf certificate
> changes and we've had no reported issues.

I'd be glad to enforce such a policy, but I'm less confident that
it'll work that smoothly.  While it would be intuitively obvious
that a server that replaces his server credential/cert should also
dispose of his server-side TLS session cache contents along with
the old credential/cert, it largely depends on how the stuff
is implemented.

There seem to be some funny server-side TLS session cache designs
out there in the wild.

A while ago I noticed that it was possible to resume a TLS session
originally established with when proposing
that session for resumption to (not using
any TLS extension here, neither SNI or TLS session tickets).

However these two servers/services use distinct server certificates,
and the server certificate returned by fails
rfc2818 section 3.1 server endpoint identification for,
which is why my SSL wrapper noticed that behaviour (the client should
not have proposed that session resumption in the underyling scenario,
so fixing it was straightforward).