Re: [TLS] Handshake not under protection

Martin Rex <> Mon, 21 December 2009 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9BCC13A6A87 for <>; Mon, 21 Dec 2009 15:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.194
X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lC1CvClnzzyG for <>; Mon, 21 Dec 2009 15:54:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 74B4A3A6A6E for <>; Mon, 21 Dec 2009 15:54:55 -0800 (PST)
Received: from by (26) with ESMTP id nBLNsbVU024051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Dec 2009 00:54:37 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Date: Tue, 22 Dec 2009 00:54:37 +0100
In-Reply-To: <> from "Michael D'Errico" at Dec 21, 9 03:29:45 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: Re: [TLS] Handshake not under protection
X-Mailman-Version: 2.1.9
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: Mon, 21 Dec 2009 23:54:56 -0000

Michael D'Errico wrote:
> Yes, you are right.  A MitM can not sign the ServerKeyExchange himself,
> but he can just ask the real server to do it.
> But this thread is about sending a client certificate in a renegotiation
> handshake, so there should be no MitM (if the client has validated the
> first handshake).
> Perhaps I misunderstood what was being asked.

Since I re-vived this thread, I'll try a summary of the latest
messages, which were about availability and security of client identity
protection through a TLS renegotiation handshake.

When servers do not ask for client certificates on the initial handshake,
but only during a TLS renegotiation, then this protectes client
identities from passive observers / passive attackers only.

If a client wants to protect his identity from active attackers (MitM)
as well, and only reveal it to selected servers, then this will require

  (1) an initial TLS handshake where the TLS server provides his
      Server certificate

  (2) an app-level determination that the authenticated TLS-Server
      to which the client identity may be revealed

  (3) a TLS renegotiation where the server requests and the client
      sends a client certificate.

A DH_anon session will not be sufficient for (1), because it
precludes (2).  The authentication of the Server in (3) happens
much too late (Server.Finished) to be usable for the determination
whether the client may a Certificate message on handshake (3).