Re: [TLS] Handshake not under protection

Marsh Ray <> Mon, 21 December 2009 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1554C3A6AA6 for <>; Mon, 21 Dec 2009 11:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ClauNkg1Fcbl for <>; Mon, 21 Dec 2009 11:37:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C30D73A67FA for <>; Mon, 21 Dec 2009 11:37:19 -0800 (PST)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1NMo3z-0008JV-Ar; Mon, 21 Dec 2009 19:37:03 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 455BD603A; Mon, 21 Dec 2009 19:37:01 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19vPCey7eWjWBU9uRJae96kDWB03NMwxpo=
Message-ID: <>
Date: Mon, 21 Dec 2009 13:37:04 -0600
From: Marsh Ray <>
User-Agent: Thunderbird (Windows/20090812)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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 19:37:21 -0000

Martin Rex wrote:
> Marsh Ray wrote:
>> At the TLS level, it's possible for the current session to be
>> anon-anon-DH, which provides no protection.
> And which rfc-5246 requires to _not_ request a client certificate:
>    7.4.4.  Certificate Request
>    When this message will be sent:
>        A non-anonymous server can optionally request a certificate from
>        the client, if appropriate for the selected cipher suite.

The client cert is requested in the renegotiating handshake, not the
initial one.  An anon-anon-DH session provides no "protection" for the
client cert passed in renegotiation.

But it probably makes some people feel more secure to not see the
details (usernames, emails, phone numbers, street addresses) flying by
on the wire.

>> In practice, client apps will hand over the plaintext client certificate
>> to any MitM that asks for it.
> Unfortunately, this observation is very true for most of the installed base.
> It may easily be wrong for clients that do care about client identity
> protection and require a TLS renegotiation before sending a client
> certificate.

I haven't yet found a client that requires renegotiation before
supplying a client cert.

I have seen common recommendations to have the server ask for it by
renegotiation, as if that were a secure solution.

> The client certificate itself is sent with whatever protection the
> record layer currently applies (non on an initial handshake) without
> any kind of additional protection in a Certificate message from the client
> to the server if the server includes a CertificateRequest message
> between ServerHello and ServerHelloDone.
> At that point, the Server is _not_ authenticated. The server has
> already sent his "Certificate" message (containing the server certificate),
> but that could be fake.  Only when the TLS handshake succeeds, the
> client knows that the provided server certificate wasn't fake


> -- and
> at that point the application could decide whether it wants to
> reveal its identity to that authenticated server through TLS
> renegotiation.

There are several significant points during the handshake that seem to
require special application-layer processing. Rarely do we see one
callback implemented perfectly, much less for two handshakes!

> Client identity protection through renegotiation _can_ be used in
> a secure fashion.

It could be done securely if the application layer specified its
operation thoroughly.

HTTPS does not, I wonder if any do?

> There is no guidance in the TLS spec how to do it,
> though, and most existing clients are willing to send a client
> certificate in any handshake.

That's my point exactly.

> A number of clients will send 
> their client certificate to servers on request in the initial
> handshake even when the server doesn't indicate that it trusts
> one of the trust anchors necessary to verify that client cert.
> (But the latter is a mitigation strategy at best).

Seems like the legit server's list of trust anchors would be trivial to

- Marsh