I'm interested to know if there is any reliance on system time (as defined by Linux or windows) when initiating a secure handshake. I'm aware that TCP typically uses a random number (RFC 1323) to provide a time stamp for message ordering, however I'm not sure of the TLS utilisation of system time. You can imagine this question being applicable to two system wishing to establish a secure connection but don't share a synchronised time.



  • The client and server random both begin with a 32-bit timestamp followed by 28 bytes of (hopefully ) cryptographically secure random. But as far as I know there is no reliance for synchronization purposes.
    – RoraΖ
    Oct 22, 2014 at 15:02

2 Answers 2


During the handshake, the client and server send each other "random values", which are sequences of 32 random bytes. The "client random" is part of the ClientHello message, while the "server random" is part of the ServerHello message.

In both cases, the first four bytes of the random value encode the current date and time (number of seconds since January 1st, 1970, 00:00 UTC). The reason why they do so is a bit unclear and has been lost in the mists of Time. The best explanation we can come up with is the following: if the client or server does not have a good source of randomness, then at least the inclusion of the time will make sure that they don't reuse the exact same "random" value. Of course, lack of a good random source is likely to induce other weaknesses (e.g. if using RSA-based key exchange, the client generates the random pre-master key, so the client MUST have a strong PRNG at hand).

In order to validate the server's certificate, the client should have an approximate knowledge of the current time, since certificates and CRL have expiry dates. This does not require that the server knows the current time; neither does it need any precise synchronization between client and server.

It has been argued that SSL can be (ab)used as a way to obtain the current time: simply connect to a SSL server; do the full handshake so that you know that you are talking to the right server; use the server's notion of time (from the first four bytes of server_random as current time). This is not reliable. From my own measurements, about 15% of deployed SSL servers are either wildly off (by years), or simply don't follow the standard and use random bytes for the first four bytes of server_random. In any case, a client shall not use the server time for purposes of validating the server's certificate: the client must validate the certificate to be sure that it talks to the right server, and the client must be sure that it talks to the right server to be able to trust that the received server_random really comes from the expected server and thus contains the right time. There is an intrinsic chicken-and-egg issue here.

From the raw SSL/TLS protocol point of view (as specified in RFC 5246), certificate validation is out of scope: the server sends some certificates to the client, and, somehow, the client gains knowledge (with some high degree of certainty) of the server's public key. In practice, clients do that by performing certificate validation, which requires (at least) a notion of current date. This need for a local clock is a known problem for embedded systems (at least, for embedded SSL client that cannot contain an hardcoded copy of the server's expected public key).

  • 4
    In TLS 1.3 the random fields will probably no longer contain the time. I think several existing client implementations have already eliminated it to avoid fingerprinting. Oct 22, 2014 at 18:53
  • 3
    I have once used the time to diagnose a network issue (namely, to demonstrate to the network people that yes, their load-balancing box was sending the requests to the wrong server). I have also used it to remotely assess whether the system clock of a given machine was correct or not. (I am often invoked to investigate problems by people who cannot or will not give me access to the actual machines. My job title should be "Oracle".)
    – Tom Leek
    Oct 22, 2014 at 19:38
  • 2
    @CodesInChaos your link now refers to a discussion related to point compression. This Let's remove gmt_unix_time from TLS message (from 11 September 2013) is probably a better reference with more details.
    – Lekensteyn
    Dec 20, 2017 at 9:42

TLS as a protocol does not depend on a the system time. The only point where the system time is used is in the Random field of the Client Hello and Server Hello handshake messages. From RFC 5246 (TLS 1.2):

Clocks are not required to be set correctly by the basic TLS protocol; higher-level or application protocols may define additional requirements

Related to the TLS protocol are certificates which have a date range where it is valid. These are of course related to a somehow synchronized time.

You must log in to answer this question.

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