Subject: Re: [TLS] TLS Digest, Vol 65, Issue 88

From: Ravi Ganesan <[email-masked]>
Date: Mon, 21 Dec 2009 10:27:38 -0800

>
>
>
> Ravi, your terminology is slightly confusing.  Renegotiation refers
> to a TLS handshake that is performed under protection of an existing
> TLS session, so the two things you could distinguish are:
>

Martin, Point well taken. Thx, Ravi

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.

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 19:55:53 +0100 (MET)

Ravi Ganesan wrote:
> >  - renegotiation with a full handshake
> >  - renegotiation with an abbreviated handshake (aka session resume)
> 
> I prefer not to think of the handshake happening "under protection" of

We might be talking past each other to some extent.

For a renegotiation handhshake, the entire handshake is encrypted,
including client_random and server_random, which means that anybody
watching it on the network can not see anything else than the
TLS record protocol on the outside (but he can see the ContentType
of the records).

The communication peers can decrypt the communication, of course.
In the specific case of the one attack described in
draft-ietf-tls-renegotiation the MitM encrypts the handshake data
received from the peer and sends it to the server into a renegotiation
handshake, and the MitM decrypts all handshake data received from
the server and sends it to the client in the clear.

If you discount the special case of the RSA-encrypted premaster secret,
there are _no_ values in the handshake data that are encrypted
"with certain keys".

In the SSL&TLS design, encryption of the communication happens exclusively
at the record layer (using records with sequence numbers).

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 12:59:07 -0600

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

At the TLS level, it's possible for the current session to be
anon-anon-DH, which provides no protection.

In practice, client apps will hand over the plaintext client certificate
to any MitM that asks for it.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 20:17:59 +0100 (MET)

Marsh Ray wrote:
> Ravi wrote:

I disagree to this conclusion about client identity protection.

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

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

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.

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

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 13:37:04 -0600

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

> protection and require a TLS renegotiation before sending a client

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.

> client knows that the provided server certificate wasn't fake

Yep.

> -- and

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!

> 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,
> certificate in any handshake.

That's my point exactly.

> A number of clients will send 

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

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 20:49:04 +0100 (MET)

> details (usernames, emails, phone numbers, street addresses) flying by

OK.  You are correct.

That provision in 7.4.4. is about the _current_ handshake only
and refers to the fact that a server has sent a "Certificate"
message prior to CertificateRequest.  Since at the point of
the handshake, the Server is _not_ authenticated.  There could have
been a certificate path validation of the server certificate,
but there is no proof yet, that the alleged server knows the
necessary private key to the presented certificate, so this
restriction in 7.4.4. does not provide security.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 21 Dec 2009 12:33:23 -0800

> restriction in 7.4.4. does not provide security.

If a DHE cipher suite is used, then the server can be authenticated
using only Certificate and ServerKeyExchange.  With RSA cipher suites,
you are correct that a client doesn't authenticate the server until
Finished verifies.

Mike

---

From: Geoffrey Keating <[email-masked]>
Date: 21 Dec 2009 14:11:33 -0800

> you are correct that a client doesn't authenticate the server until

I think that still doesn't prove that there is no man in the middle.
The MITM could forward the ClientHello to the real server, which will
return a signed ServerKeyExchange with the correct client_random and
server_random.  The MITM won't be able to use the associated DH
parameters but they aren't necessary until later in the exchange.

Even sending the client certificate by renegotiating under an
anonymous connection provides protection against any attacker who can
see traffic but cannot (or does not want to) perform an active attack.
I don't think it's generally useful to do start off anonymous, though,
because the server is going to have to provide a certificate later
anyway.

Another approach, of course, is to not put unnecessary personal
information in the client certificate in the first place.

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 23:22:54 +0100 (MET)

> you are correct that a client doesn't authenticate the server until

I'm not sure I can follow why you think it is protected.

RFC-5246, 7.4.3.  Server Key Exchange Message

      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              case dhe_rsa:
                  ServerDHParams params;
                  digitally-signed struct {
                      opaque client_random[32];
                      opaque server_random[32];
                      ServerDHParams params;
                  } signed_params;
              case rsa:
              case dh_dss:
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
              /* may be extended, e.g., for ECDH -- see [TLSECC] */
          };
      } ServerKeyExchange;

There is signed_params in the Server Key Exchange Message, but
it does _not_ seem to protect from MitM (when the attackers objective
is to elicit a Certificate message with the client's identity
from the attacked client).

If an attacker has a rogue server that wants to determine the client's
identity, then this attacker could open a connection to the particular
server to which it knows the client will reveal his identity,
resend the ClientHello just received and obtain a ServerHello and
ServerKeyExchange that match and then replay this information to
the client (i.e. the server_random used by the real server and
the signed_params sent by the real server.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 16:47:28 -0600

> the signed_params sent by the real server.

I think you stopped too soon:

http://tools.ietf.org/html/rfc4346#page-42
>               case diffie_hellman:
>                   ServerRSAParams params;
>        } ServerParams;
>       params
>           The server's key exchange parameters.
> 
>       signed_params
>           For non-anonymous key exchanges, a hash of the corresponding
>           params value, with the signature appropriate to that hash
>           applied.
> 
>       md5_hash
>           MD5(ClientHello.random + ServerHello.random + ServerParams);
> 
>       sha_hash
>           SHA(ClientHello.random + ServerHello.random + ServerParams);

AFAICT, MitM is forced to pass the same DHE params from the server to
the client, else he breaks the signed hash which covers ServerParams.

Since he passes the correct DHE params S->C, he cannot intercept the
traffic from client to server.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Dec 2009 23:48:55 +0100 (MET)

There seems to be a slight confusion based on me quoting only part
of Marsh' reply, and not the part the confirms the technical possibility
of client identity protection (below).

I confirmed that the restriction in rfc-5246 7.4.4. Certificate Request
"A non-anonymous server can optionally request a certificate from the client"
can not protect against server that wants to elicit a "Certificate"
message from TLS clients in order to reveal the identity of these clients.

> renegotiation, as if that were a secure solution.

Correct.  This will protect client identies only from purely
passive observers/attackers.

> > certificate in any handshake.

OK.  How about this characterization then:

Although it's technically possible to implement client identity
protection securely with the existing protocol, it is so significantly
underspecified that it makes it unlikely that even those clients
which care about this, implement it in a secure fashion today.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 Dec 2009 16:57:23 -0600

> which care about this, implement it in a secure fashion today.

Good. I would just add:

A server-only solution may prevent disclosing the client certificate to
a passive observer, it will not protect it from an attacker who can act
as an active man-in-the-middle for the underlying transport.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Mon, 21 Dec 2009 15:29:45 -0800

> parameters but they aren't necessary until later in the exchange.

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.

> information in the client certificate in the first place.

I have seen someone send a client certificate to my server with a
subject that had most attributes containing the string "confidential"
and the commonName was basically a unique ID.  The only possibly
identifying information was the country code, and based on a recent
PDF I've read I have a "theory" of who it was!  ;-)

Mike

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Dec 2009 00:54:37 +0100 (MET)

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

-Martin