5

In SSL/TLS handshake, a nonce is always sent by the client to server and vice versa. The nonce basically consists of a random number and unix timestamp. Why do we need the unix timestamp?

As the nonce is always a random number, how does this protect from replay attack by a man-in-the-middle? Being a random thing, same nonce might be repeated in another handshake with the same server.

Can somebody tell me any other purpose of this nonce?

D.W.
  • 98,860
  • 33
  • 271
  • 588
asit_dhal
  • 169
  • 1
  • 1
  • 6

2 Answers2

4

The server should never allow a duplicate nonce. This is what protects from a replay attack. Someone can capture and try to re-send your message but it will be denied because that nonce has been recorded and can't be used again.

If you have a timestamp and deny requests older than say 5 minutes, then you can clear cache of used nonces every 5 minutes. You can clear your nonces because even if they replayed one at this point it will see the timestamp is expired and fail anyway. This means you don't have to keep every nonce ever used until the end of time which results in less storage space and faster lookup times.

Despertar
  • 457
  • 1
  • 3
  • 11
  • 7
    This answer is wrong. The server doesn't need to remember old nonces from past connection attempts. The server has its own random number that it sends during the handshake, and the server's random number protects the server from replay attacks, so there's no need for this. (The client also sends a random number, which protects the clients from replays. So, both endpoints' interests are protected. Neither needs to remember past nonces.) – D.W. May 07 '16 at 02:30
  • If all you had was a random number, this would do nothing to prevent someone from replaying the message with this random number again and again. I think an alternative to what I described would be using a sequence number which is incremented for each request. Any message sent that is not the next number in the sequence would be denied. What I described is from API's I've seen such as Netflix's. The nonce in this case is not incremented, but a random number sent everytime. But again, a random number can be replayed unless you kept track of which ones you have seen, so it would be pointless. – Despertar May 07 '16 at 04:29
  • 4
    That's not correct. I sense some confusion. The TLS handshake involves *two* nonces, one chosen by the client and one chosen by the server. There is no need to remember past nonces. No TLS implementation does that, and it's not necessary. *"If all you had was a random number, this would do nothing to prevent someone from replaying the message with this random number again and again"* - That is not correct. If Mallory replays the client's messages in a second TLS handshake, the *server*'s nonce will prevent this from doing Mallory any good. Again, there are *two* nonces, one from each party. – D.W. May 07 '16 at 18:18
  • This answer http://security.stackexchange.com/a/20106/10327 points to the RFC which says "To prevent message replay or modification attacks, the MAC is computed from the MAC secret, the sequence number, the message length, the message contents, and two fixed character strings. The sequence number ensures that attempts to delete or reorder messages will be detected". – Despertar May 07 '16 at 23:33
  • That's the record layer protocol. The two nonces are sent during the TLS handshake, and are used (together with the premaster secret) to derive the symmetric keys and MAC keys used in the record layer protocol. The question refers to a nonce that's built out of a random number and a timestamp; that's referring to the random numbers sent as part of the handshake (the standard calls for the random number to contain 4 bytes of timestamp and 28 bytes of randomness, or something like that). – D.W. May 08 '16 at 05:29
1

In TLS 1.2 and before, the Random field of the Client and Server Hello messages indeed have a random bytes part and a timestamp. The purpose of the timestamp is to increase the chance to have a unique value even if the random number generator is flawed and produces duplicate random bytes.

This however is not the current practice, modern TLS implementations just send a completely random sequence due to privacy concerns (leaking the local time). For this reason the time part has been removed in the TLS 1.3 draft.

The random numbers from both sides are combined with another shared secret to form a session key (see RFC 5246 TLS, Key calculation). So even if one side sends a duplicate random sequence in the hello handshake message, it will not result in the same session key.

Community
  • 1
Lekensteyn
  • 5,958
  • 5
  • 38
  • 62