SSL replay attack when client/server random is missing

Question

Hey studying the SSL protocol, I'm wondering how can someone be able to do a replay attack if the server nonce is missing? All the material I find says that nonces prevent it, but theres no examples which specify why or how

Answer 1

If the server uses the same nonce (called "server_random" in the SSL/TLS specification) and the same session ID than for a previous handshake, then an attacker can send the exact same packets than what the client sent during that previous session, and the server will accept the whole thing. At least if the server uses a RSA key exchange cipher suite (which is the most common case).

This can easily be seen by following how the various cryptographic elements are computed. The ClientKeyExchange message contains the pre-master-secret, encrypted with the server public key; that packet can be replayed and is still a properly encrypted version of the same pre-master-secret. The encryption and MAC keys are then derived from the pre-master-secret, the client_random and the server_random, through the SSL/TLS "PRF" which is deterministic. Thus, if the randoms are unchanged (i.e. if the server uses the same server_random than previously, and the attacker sends the same ClientHello message than during the previous session) and the pre-master-secret is also unchanged, then the server will infer the same symmetric keys and will thus accept the captured encrypted packets as being genuine.

The attacker doing the replay would not gain any extra insight as to what the application data could look like; the attack is not a decrypting attack. But from the server point of view, this would look like a second genuine, voluntary connection. For a SSL connection used for a HTTPS POST request for a credit card payment, this would mean a double payment.

Fortunately, it takes incompetence of non-standard magnitude to achieve a SSL server which always uses the same server random and the same session ID. I am not saying it never happens; only that it happens rarely. Notably, the TLS specification insists on the idea that the first four bytes of the client_random and the server_random should encode the current date and time, with a 1 second accuracy: if honored, even with a badly skewed clock, this alone ensures that a server with a badly flawed RNG will still use a distinct server_random after one second.