6

Note I have read Why does the SSL/TLS handshake have a client and server random? and the answer makes it clear why the server random is necessary. However, since the premaster secret includes the client random, it seems like including the client random with the premaster secret when generating the master secret is superfluous.

Kent Shikama
  • 171
  • 1
  • 5

2 Answers2

8

For ciphersuites based on a key exchange and a signature as proof of possession, the sole way the server proves its identity is with the signature in the server key exchange message. This signature is tied to the TLS session because the signed data includes the client random and the server random. Apart from the client random, everything is chosen by the server, therefore the client random is the only thing that prevents anybody else from pretending to be the server after observing a single message from the server. A client trying to contact the legitimate server has no way to know that the server random isn't being repeated by an attacker. The client random is how the client challenges the putative server to prove that it is legitimate.

Even for ciphersuites where the client selects the pre-master secret and the server needs the private key to decrypt it, without a client random, two requests to the same server (with the same options) differ only because they have different server randoms. If I record a valid session then I can replay it to any client. I might not know what I'm sending, but I can at least feed obsolete information to clients that make identical requests.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • It seems at least for the plain-RSA key-exchange two requests to the same server (with the same options) differ because their pre-master secret (which contains client generated random values) is different. – Kent Shikama Apr 21 '17 at 18:43
  • 1
    @KentShikama I think you're right in that removing the client random wouldn't *immediately* compromise tls: for dhe type ciphersuites, even if an mitm can replay a message from the server, they still won't be able to reconstruct the shared symmetric key so it's effectively useless. Similarly for rsa-type keyexchanges the pre-master secret is still random between sessions, so tls isn't immediately broken. Thus I think the client random mainly provides defense in depth. And in particular increases keystrength of the final master secret since both sides contribute. – 1110101001 Jul 22 '20 at 20:02
  • This answer itself seems to ignore the fact that premaster secret contains client random, emphasized in the very second OPs sentence. And thus the whole two paragraphs of answer text become almost unrelated. Probably the text from the comment above should find its way to the answer. – Alex Che Sep 05 '22 at 15:26
  • Sorry, I've meant not "client random", but "some random data from client" in my comment. But time for corrections is already gone. – Alex Che Sep 05 '22 at 15:41
-1

The premaster secret does not contain the client random. It is a random key of its own. It is distinct from the client random because the client random is sent in the clear while the premaster secret is encrypted with the server public key.

John Wu
  • 9,181
  • 1
  • 29
  • 39
  • 1
    Well then it seems like only the premaster secret along with the server random without the client random would do as the premaster secret contains a random value generated by the client? – Kent Shikama Apr 20 '17 at 03:06
  • 2
    **For plain-RSA key-exchange** the premaster secret is a client selected random value (but as you say not hello.random); for any form of DH or ECDH it is instead the result of a key agreement using shares from both; and for other less-common key-exchanges it is several other things. – dave_thompson_085 Apr 20 '17 at 04:45
  • 1
    @dave_thompson_085 So would it be accurate to say that the hello.random is superfluous for plain-RSA key-exchange? – Kent Shikama Apr 21 '17 at 18:42