In the SSL handshake both the client and server generate their respective random numbers. The client then generates a pre master secret and encrypts it with the server's public key. However, why can't the client just generate the pre master secret and send that to the server? Why do we need a client and server random? Is it to contribute to the entropy in the master secret, or for uniformity with other key exchange algorithms such as DH?
Asked
Active
Viewed 1.8k times
4 Answers
38
From The First Few Milliseconds of an HTTPS Connection:
The master secret is a function of the client and server randoms.
master_secret = PRF(pre_master_secret,
"master secret",
ClientHello.random + ServerHello.random)
Both the client and the server need to be able to calculate the master secret. Generating a pre-master secret on the client and just sending that to the server would mean the the client never gets to find out the master secret.
Why not just use the pre-master?
This would mean that the entire key generation routine was based on client generated values. If a Man-In-The-Middle attacker replayed the handshake, the same pre-master secret would be sent and then used for the connection. Having the server generate a random value (ServerHello.random) will mean that the MAC secret is different if the ClientHello.random is repeated, and therefore the MAC and encryption keys will be different, preventing any replay attack.
SilverlightFox
- 33,408
- 6
- 67
- 178
-
3For newcomers who don't understand the last paragraph : [Why using the premaster secret directly would be vulnerable to replay attack?](https://security.stackexchange.com/q/218491/159875) – Rick Sep 23 '19 at 04:06
-
TLS 1.3 uses ephemeral keys generated by both the client and server. Would this not prevent a replay attack? What is the need for the client and server random in TLS 1.3? – JBis Dec 09 '21 at 18:47
-
@JBis Yes it would. The client and server ephemeral keys are instead of the secrets AFAIK. – SilverlightFox Dec 15 '21 at 08:54
-
why does sending pre-master secret wihout encryption would lead to client never being able to generate master secret? – YFlag May 20 '22 at 04:59
-
For those who wants to know why client random is needed, having premaster secret already contains random data from client, see [Why does the SSL/TLS handshake have a client random?](https://security.stackexchange.com/q/157684/237139). (Although the answers there still do not seem to be very explaining for me, as for now.) – Alex Che Sep 05 '22 at 15:36
0
Is it to contribute to the entropy in the master secret...
Yes. It ensures both parties contribute to the master secret.
The master secret is the seed used to derive the subsequent keys used for bulk encryption and authentication.
... or for uniformity with other key exchange algorithms such as DH?
No. Diffie-Hellman requires both parties to contribute by selecting a random secret value a (or b), and then sending the other party the A=G^a (or B=G^b). Contributory behavior is baked into Diffie-Hellman.
There are other Key Agreement schemes. RSA is a Key Transport schemes, but it does not offer the opportunity for the server to contribute to the premaster secret. That is, there is no contributory behavior inherent to RSA key transport.
In the case of RSA key transport, the way to ensure both parties contribute to the master secret is:
master_secret = Transform(premaster_secret + client_random + server_random)
A practical problem the contributory behavior solves is, imagine an IoT device that has a broken or useless random number generator. The contributory behavior ensures the channel is [mostly] secure even when the client lacks randomness.
0
Useful when resuming a session
In TLS, the master secret is used with server and client random bytes in a PRF function to calculate a key block.
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random)
Then the key block is divided to provide six keys used for different operations :
- 2 encryption keys
- 2 MAC keys
- 2 IV (when needed by encryption primitive)
When resuming a session, the same master key is used to generate key block. So use of client and server random bytes ensures that key block will be different in every handshake.
Daryl Bennett
- 113
- 6
chamoute
- 71
- 4
-3
It is part of the Handshaking. it exposes the premaster secret but only to the server and client not to anyone in between. No one but the server can access the secret generated by the client due to no one but the server having the secret key to decrypt with.
Apparently my awnser is lacking Quoting @Raz here to make it a better awnser. (incorperated into my awnser above)
no the premaster secret is encrypted with the server's public key. The client and server ransoms are used with it (and other constants) to generate the Master key. Which is then used to generate sessions keys. Might want to read the answers for How Does SSL work for more details on the handshake
LvB
- 8,217
- 1
- 26
- 43
-
4This is just wrong. The client and server randoms are sent in the clear. Anyone can see them in between. – RoraΖ May 16 '15 at 14:21
-
How its encrypted with the Servers secret key... Or my knowledge of the SSL exchange is lacking (always possible) – LvB May 16 '15 at 14:46
-
No the premaster secret is encrypted with the server's public key. The client and server ransoms are used with it (and other constants) to generate the Master key. Which is then used to generate sessions keys. Might want to read the answers for [How Does SSL work](http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work) for more details on the handshake. – RoraΖ May 16 '15 at 14:48
-
-
1The OP is asking about the Client Random and Server Random values, not the pre-master secret. Which I see now is what you're referencing, but it is not the answer to the question. – RoraΖ May 16 '15 at 14:52