Re: [TLS] Handshake not under protection

Martin Rex <> Mon, 21 December 2009 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF1053A690D for <>; Mon, 21 Dec 2009 11:18:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.193
X-Spam-Status: No, score=-6.193 tagged_above=-999 required=5 tests=[AWL=0.056, 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 QOp8uVrDIBYv for <>; Mon, 21 Dec 2009 11:18:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BC1D63A67FA for <>; Mon, 21 Dec 2009 11:18:19 -0800 (PST)
Received: from by (26) with ESMTP id nBLJHxfg000537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Dec 2009 20:17:59 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Date: Mon, 21 Dec 2009 20:17:59 +0100
In-Reply-To: <> from "Marsh Ray" at Dec 21, 9 12:59:07 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 19:18:21 -0000

Marsh Ray wrote:
> Ravi wrote:
> >
> > p.s. I prefer not to think of the handshake happening "under protection"
> > of previous session. Another example of this is in current draft which
> > says: "The handshake is in the clear to the attacker but encrypted over
> > the attacker's TLS connection to the server." The handshake itself is
> > always of course is in the clear, certain values in it are encrypted
> > with certain keys. And in some cases this results in binding to previous
> > sessions. This sounds nitpicky, but I only say this because perfectly
> > smart security people with some knowledge of SSL can read sentences like
> > above to assume the entire handshake (including client_random and
> > server_random) is encrypted.
> +1.
> There is no "protection" being provided. People who are thinking
> renegotiation provides real security for client certificates are
> somewhat misguided.

I disagree to this conclusion about client identity protection.

> 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.

> 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

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

Client identity protection through renegotiation _can_ be used in
a secure fashion.  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.  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).