TLS replay attack - requirements of the serverHello nonce

Question

As you all know, the SSL/TLS protocol requires both client and server to exchange (in clear text) a random number or nonce. This is presumably used to prevent replay attacks.

It is not clear to me what the server-side nonce requirement is. Must it simply be unique? Or must it also be unpredictable? What would be the implications if an attacker could predict the nonces generated on the server side, if any?

I welcome any source of serious work around replay attacks that could help better understand the server side nonce requirements.

Thanks.

Louis

Answer 1

Within SSL/TLS, the nonces are used for generating symmetric keys, and as part of the signatures and checks during the handshake. For all those usages, the nonces are simply concatenated (with some other data) and hashed. Assuming that the hash functions behave like "random oracles" (the mythical perfect hash function), then unique nonces are sufficient.

However, SSL/TLS up to (and including) TLS 1.1 uses MD5 and SHA-1 as hash function, for which weaknesses have been demonstrated. They are not random oracles. I am not aware of any result about turning these weaknesses into attacks on SSL/TLS itself; however, better be safe than sorry: use unpredictable nonces. This will not harm, and both client and servers must already have access to a cryptographically secure source of alea, hence unpredictable nonces should not be a too heavy requirement.