0

The client random is enough to prevent replay attack. The server signs the client random when sending the serverkeyexchange, so an attacker can't replay a session because client.random is different.

What is the purpose of server.random ?

confused_openssl_user
  • 9
  • 1
  • I'm not a subject-matter expert and I certainly will not argue but "The client random is enough to prevent replay attack" needs a good reference in order to make such radical statements. – CriticalSYS Nov 01 '20 at 15:43
  • I said why I think it's true. I'm not an expert either, just a learner, but if the server signs the client random then replay attack won't be possible, since, in a new session, the replayer cannot re-use the old signature to send a valid pair. – confused_openssl_user Nov 01 '20 at 16:01
  • @confused_openssl_user you may be making the assumption that the client is behaving properly - each party contributes to the overall CS-entropy, so that no one party can unduly influence the spread of possible states that could then be used as an advantage for key discovery, **or** that both parties can benefit from the 'unpredictability' of the other (think along the lines of a newly booted client that has engaged in very little network activity, and has no carry-over from the previous session) – brynk Nov 01 '20 at 21:46
  • In the TLS versions that have ServerKeyExchange (1.0 through 1.2, not 1.3) the server does NOT sign client random, and even if it did that wouldn't prevent replay because replay uses the _same_ client random. – dave_thompson_085 Nov 02 '20 at 00:33
  • @brynk So you mean that if for example a client had a flawed RNG that outputs the same nonce every time, an attacker could pretend to be the server and replay an old session (he has valid pairs (client.radom, signature(client.random)) ? – confused_openssl_user Nov 02 '20 at 18:27
  • @dave_thompson_085I dont understand your last comment, the client random won't be the same, so the attacker can't get the new client.random signed to send it back to the client even if he has an old session – confused_openssl_user Nov 02 '20 at 18:29
  • @confused_openssl_user not just the nonce, but all the ephemeral components of the session key, and not just avoiding a targeted replay, but the reduction in the search space for attempts to force the session key. The client and server randoms will likely feed into the host kernel's CSPRNG, as well as being hashed during the key derivation, which ties the subsequent session key to the early inputs of the protocol. Some helpful resources: https://tls13.ulfheim.net/ and *T.Pornin 2010* https://stackoverflow.com/a/3532136 and *Perrin 2018* https://youtu.be/3gipxdJ22iM?t=1043 – brynk Nov 02 '20 at 23:27

0 Answers0