Subject: [TLS] Also, on client-random and server-random

From: Ravi Ganesan <[email-masked]>
Date: Tue, 2 Feb 2010 20:22:25 -0800

FWIW, in my deconstruction of why these values exist, it seemed to me
that if you ran the full handshake with only the server-random, and
the abbreviated handshake with only the client-random, you were ok
against the attacks known. (not suggesting one run it without both;
just making an observation as it helps us analyze the importance of
the server-random in abbreviated hanshake).

---

From: Adam Langley <[email-masked]>
Date: Wed, 3 Feb 2010 05:16:48 -0500

On Tue, Feb 2, 2010 at 11:22 PM, Ravi Ganesan <[email-masked]> wrote:
> that if you ran the full handshake with only the server-random [...] you were ok

Consider a TLS connection using DH that I just sniffed from the network.

If there's no client random then what stops me from intercepting
future connections from the same client, to the same server and
replaying the server's side to the client? The server random would be
the same, as would the DH value and signature. I think, from a quick
thought experiment, that the master secret would end up the same and
the client would accept it. There's no reason that the client is
required to use a different DH public value.

AGL

---

From: Ravi Ganesan <[email-masked]>
Date: Wed, 3 Feb 2010 04:16:00 -0800

Sorry my comments were
i) only meant to apply to RSA based ciphersuites (all we support as
yet in MashSSL).
ii) And, I said it exactly backwards.

In the abbreviated handshake as S does not know who C is upon getting
a client-hello, if you did not have the server-random, then a
malicious client could (if there were no other checks), get the server
to provide a large number of server-finisheds to carefully chosen
client-randoms, w/o completing the protocol.

Conversely, in the full handshake as C does not know who S is when
computing certificate-verify (assuming it is requested), a malicious
server could (if there were no other checks), get the client to
provide a large number of certificate-verifies on carefully chosen
server-randoms w/o completing the protocol.

Again, there was a time in SSL when these two random numbers were NOT
in protocol, (see this description of SSL 2.0
http://www.mozilla.org/projects/security/pki/nss/ssl/draft02.html for
instance) and then they appear. I was trying to understand the
motivation for why they were added in, and the above two reasons were
all I could find.