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

mrex@sap.com (Martin Rex) Tue, 04 March 2014 19:56 UTC

Return-Path: <mrex@sap.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 544ED1A01C1 for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 11:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-6c1VBf0YRu for <tls@ietfa.amsl.com>; Tue, 4 Mar 2014 11:56:18 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DC4CF1A01B0 for <tls@ietf.org>; Tue, 4 Mar 2014 11:56:17 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (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: <CAL9PXLy4KM_bqS3biRqOMsZ7j+mA6uu75GqJVmBF9wC98_3aQA@mail.gmail.com>
To: Adam Langley <agl@google.com>
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: <20140304195610.7AF1F1AC3B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bZJe6pbXE-vi2leoQ7dtQ9TAvug
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
Reply-To: mrex@sap.com
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 19:56:21 -0000

Adam Langley wrote:
> Dr Stephen Henson <lists@drh-consultancy.co.uk> 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 https://www.google.com/ when proposing
that session for resumption to https://docs.google.com/ (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 https://www.google.com/ fails
rfc2818 section 3.1 server endpoint identification for docs.google.com,
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).


-Martin