I know the common usage of nonces in security (which is well described in this topic). However, when checking the SSL/TLS protocol, we can notice, according to the RFC, that nonces as ClientHello.random and ServerHello.random are sent in plaintext and could be easily replayed by an attacker. Why are they still used in TLS1.2 then ? Are they only there for differentiating an user for another ? They are actually no challenges performed with them.

I am here mentioning the specific case of SSL/TLS (TLS1.2), and would like to know if, in this case, the usages of their nonces have an impact on the security at any step of the protocol. If not, why has it been introduced ?

The accepted answer to this question describes why, when using the specific case of TLS/SSL, nonces aren't needed as strong authentication is used on the channel, so are they actually useless in the protocol ?


  1. Nonces (date + alea) are sent in plaintext, we can therefore consider them as public data for a user, since any attacker could get them by listening the exchanges between the client and the server.

  2. Considering 1) and the fact that the RFC specifies nowhere if we have to check the nonces at any step of the protocol, the replay attack is still possible.

Therefore, why shall we take these data as security parameters if they are "public" ? If they are not security parameters, are there usages limited to an identifier of the client/server ?

  • I hope I have clarified the meaning with that edit.
    – Rory Alsop
    May 20, 2014 at 9:45
  • @RoryAlsop Yes, thank you very much for the edit and your understanding.
    – blingbou
    May 20, 2014 at 9:49
  • While the attacker can replay the clients nonce to the server, it can't force the server to replay the nonce that the server sent previously.
    – jjanes
    May 20, 2014 at 20:53

3 Answers 3


Nonces do not require secrecy. The virtue of a nonce is to occur only once, not to be unknown to outsiders. The fact that the client random and server random are sent as cleartext does not prevent them from being "nonce".

The actual "nonce" is the concatenation of the client and server random. This is explicit in several places, especially in section 6.3 of RFC 5246, which deals with key computations: the symmetric keys used for encryption and MAC of application data are derived from a combination of the "master secret" and the concatenation of both randoms:

  key_block = PRF(SecurityParameters.master_secret,
                  "key expansion",
                  SecurityParameters.server_random +

The two random values will also occur in the computations for the CertificateVerify and Finished messages, since both use a hash value computed over all the previous handshake messages, which includes the two "hello" messages and the random values they contain.

So the client random protects itself by sending a new client_random: whatever happens on the wire, the client will use the random value it sent for key computations. Similarly, the server protects itself with its server_random. To see how the protection works, consider a replay attack: the attacker observed a handshake between a client and a server, and then wishes to replay the same handshake with the server, thereby impersonating the client. The attacker observed this:

ClientHello (ch1)            --->
                             <---        ServerHello (sh1)
                                         Certificate (c1)
                                         ServerHelloDone (shd1)
ClientKeyExchange (cke1)     --->
Finished (cf1)
                             <---        ChangeCipherSpec
                                         Finished (sf1)

The attacker then connects to the server, and sends an exact copy of the ClientHello (ch1). The server, however, responds with a distinct ServerHello (let's call it sh2): that ServerHello is very similar to the one used previously (sh1), but with a new server_random value. The attacker can then proceed with the handshake, but things will fall apart when the attacker sends the Finished message cf1: that message should contain a hash derived from all previous handshake messages, and be encrypted with keys derived from the master secret (that the attacker does not know, he merely "replays") and from both client and server randoms. For both computations, the server expects the Finished contents and the keys for encryption to have been derived using the random from the ClientHello and from its own ServerHello (i.e. here the "sh2" message). The "cf1" message won't match, since it was computed with hashes and keys from the initial handshake, with the randoms from ch1 and sh1, not sh2.

The recorded packets cannot be all replayed by the attacker because, by definition, the attacker replays only half of the conversation. When the attacker tries to impersonate the client, he can send all the packets on behalf of the client, but must work with what the genuine server responds (if the attacker impersonates both client and server, then he can do a "perfect replay", but he is actually talking to himself only, so this is considered a mental illness, not an attack). The server_random thus enforces a divergence which thwarts the replay attack.

(A similar case can be made with an attacker trying to impersonate the server when talking to a genuine client: the client_random protects the client against that replay attack.)

Alternative description: the client and server actually do verify nonces. They do so implicitly when they compute the symmetric keys, and check the contents of the received Finished messages. The client won't be content with a received Finished message from the server unless that message was computed and then encrypted using (among other values) the client_random that the client just sent, and none other (and similarly for the server).

The client and server "randoms" need not actually be random, although it is advisable. As explained above, the real value in the client and server random values is that they are distinct from previous values, for each handshake. They are public values, and there would not be any serious issue if they were predictable. Indeed, even if the attacker can predict the exact values of the client_random and/or server_random that will be used by given clients and servers, this won't help him running his replay attack: to succeed at replaying a handshake, the attacker must not simply know the client and server randoms; he must arrange for both client and server to reuse the same randoms as in the previous handshake which is replayed. Since the attacker impersonates only one at a time, he cannot enforce such reuse.

You may note that the said 32-byte randoms actually begin with 4 non-random bytes: these bytes encode the current date and time (number of seconds since a conventional instant). The purpose of these bytes is to try to ensure this non-reuse policy even for implementations with so terribly dysfunctional PRNG that they reuse previous random values. However, if the client has no good random source, this may have impacts on the security of the ClientKeyExchange and the master secret, especially with RSA-based key exchange (as is commonplace).


It prevents replay attack. Consider a scenario where an attacker is recording all the communications between client and server. After that the attacker reconnects to the server and sends back all the recorded messages to the server. TLS prevents this attack by using nonce or connection-id, which is unique to the connection. Attacker cannot predict nonce in advance, since nonce is generated using some random events i.e date, time etc.,so the attacker cannot properly respond to the server requests. If an attacker is having high end systems, so he can record many sessions between client and server. After that the attacker can make an attempt to choose the correct session based on the nonce send by the server in SERVER_Hello message. TLS protocol uses atleast 128bits nonce and maximum is 224bits long, so the attacker would need to record 2^64 or 2^112 nonces to even have a 50% chance of choosing right session. It is difficult to have a device that record 2^64 or 2^112 messages.

  • 2
    No, I don't think so. As implied by the RFC, it does not prevent replay attacks, since nonces are sent in plaintext during ClientHello and ServerHello. Any attacker could simply listen what goes between the client and the server and use them afterwards. Furthermore, even though a datation is included in the nonce, nothing is specified in the RFC about the check of the date. So considering the RFC, nonces doesn't prevent any replay attacks, explaining my question.
    – blingbou
    May 20, 2014 at 12:24
  • I know its plaintext. Do one thing open wireshark and capture ssl packet, then you can see there is a date and time in random data. It is not as simple as you are telling.
    – ifexploit
    May 20, 2014 at 12:55
  • 2
    I already did it and yes that's my point. What is the usage of this nonce (date+alea) if it is sent in plaintext (that could be replayed by an attacker) ? Indeed, where does the RFC mention the nonce check in time (by Server or Client side) ? Nowhere after my reading, that's why I am wondering why this nonce is required. Do you see my point there ? (please keep in mind that I am talking about the protocol, not the implementation)
    – blingbou
    May 20, 2014 at 13:07
  • 2
    If the nonce used for session, then it is not a security parameter, right ? "If nonce has not been used then anyone can replay the recorded message anytime to the server" could you please show me your RFC sources for this if test ? I am quite interested by that.
    – blingbou
    May 20, 2014 at 13:56

It prevents replay attacks

Steps 4 and 5 of the handshake are in the following manner

4. c --> s: <AUTHc>
5. s --> c: <AUTHs>

c is the client
s is the server
<> means encryption using the record protocol with the shared key (Kcs) between c and s
AUTHc is a token in the form of prf(Kcs, **transcript of messages 1,2**)
AUTHs is a token in the form of prf(Kcs, **transcript of messages 1,2,3**)

prf is a pseudorandom function with the key and a transcript of certain messages as input.
The transcript is essentially a hash of a certain number of messages.

Nonces are in messages 1 and 2 and included in these tokens, hence avoiding replay attacks.

  • I edited my topic in order to show how it can not prevent replays attack according to the RFC
    – blingbou
    May 21, 2014 at 7:20
  • It is the same I said. My message 4 they call 7.4.8. Certificate Verify and message 5 is 7.4.9. Finished. May 21, 2014 at 10:45
  • 2
    Since these data are sent in plaintext, it can still be replayed by any part of the connexion. Plus, no check is performed on the nonce when received, according to the RFC.
    – blingbou
    May 21, 2014 at 11:27
  • 3
    for sure nonces are sent in plaintext. And the CertificateVerify is not always required (so the client is not always authenticated). When RequestCertificate is not sent by the server, data are not signed by client side, so your argument about signature is not always valid.
    – blingbou
    May 21, 2014 at 11:59
  • 1
    What do you mean by freshness (I don't know that concept) and how do you define it please ? Could you provide me any sources about that please, I am quite interested about this concept in security.
    – blingbou
    May 21, 2014 at 12:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .