We've recently implemented WS Trust security over SSL for our client / server communications. Our application is used by thousands of our customers, spread out all over the world. One of the problems we've had in the past with secure communications is that customers with unsynchronized clocks have difficulty connecting, resulting in customer calls and frustration. Unfortunately, the reaction that has caused in the past is to simply disable this check or simply increase the acceptable clock skew to near infinite amounts.

I do not want the security of our system to be compromised, nor do I want to trigger an influx of complaints of customers who do not have their clocks closely in sync with the time on our servers (which are synced to internet time). In order for me to prevent the synchronization check from effectively being disabled, I must first be able to explain to my managers why this is a bad idea, and why the benefits of clock synchronization outweigh the cost of customer complaints or confusion.

  1. What role does clock synchronization play in SSL communications and what sorts of vulnerabilities does disabling it introduce?
  2. What is typically considered to be the maximum acceptable range for clock synchronization in secure customer facing applications?

2 Answers 2


In SSL, clocks are used for certificate validation. The client needs to make sure that it talks to the right server; for that, the client will validate the server's certificate. Validation implies verifying a lot of things; two of them involve clocks:

  • The server's certificate (and all involved CA certificates) must include the present time in their validity time range. Each certificate as a notBefore and a notAfter fields; the current time must fall between these two dates.

  • The client is supposed to obtain the revocation status of each certificate, by obtaining (and validating) a CRL (Certificate Revocation List) from the appropriate issuers (the CA). A CRL is deemed acceptable if (in particular) it is "not too old": again, the CRL has a thisUpdate field that says when it was produced, and a nextUpdate field that more-or-less serves as expiration date for the CRL.

If the client's clock is off, then it will break either or both of these functionalities. For instance, the server's certificate will be considered as "long expired", or "not usable yet", leading to rejection.

Accepting that the client's clock is off means that the client is modified to disregard dates in certificates and CRL. The ultimate consequence for security is that if an attacker succeeds in stealing the private key of a server, then that attacker will be able to impersonate that server forever. The point of revocation is to have a verified method to recover from such a compromise; and the point of certificate expiration is to keep CRL from growing indefinitely. If clients disregard revocation and/or expiration, then the raw consequence is that once a compromise happens, then you are doomed forever. Which is usually considered to be a bad thing.

On a brighter note, this is a problem for clients, not for the server. If you operate the server, then it is the client's job, not yours, to validate your certificate properly. If the client really insists on doing things insecurely and being vulnerable, then you cannot really prevent it, at least not technically (you can do things contractually: if the client's incompetence allows for a breach, the client should pay for it).

On a similar note, if the clients can talk to your server, then they are connected to some sort of network, meaning that Internet-based time synchronization is a possibility. Requiring an accurate clock is challenging for some embedded devices, but it should not be for networked computers (including smartphones).

  • 1
    Certificate validation could be a problem for servers if client certificates are being used, but that isn't the common case. Nov 13, 2014 at 17:49
  • Can an hour or 2 difference between client clock and reality cause this breakage? Or how much does the client need to drift for it to be a problem?
    – schroeder
    Nov 13, 2014 at 18:19
  • 7
    The Microsoft CA software ("AD Certificate Services") emits certificates ten minutes in the past so that each certificate can be used immediately, even if with machines that are off by up to 10 minutes. A clock difference of more than 10 minutes can thus imply breakage. The same happens with CRL: the CRL issuer must take care to issue CRL with a thisUpdate artificially set in the past to avoid such issues; there again, AD CS uses the "10 minutes" rule. Nov 13, 2014 at 18:29
  • Relevant: imperialviolet.org/2014/04/19/revchecking.html
    – user541686
    Nov 13, 2014 at 19:47
  • I was thinking to get date and time from the error message I get while trying to establish the connection with the server (when I first boot my system, i.e., date and time is incorrect). However, from your answer it looks like it fails in SSL handshake (way before sending data over HTTP). Am I correct?
    – abhiarora
    Nov 3, 2019 at 14:12

Simple version (for managers): Time syncs can prevent replay attacks. Without them, someone could record the packets sent between client and server, decrypt, modify data, then resend the packet stream and no one would be the wiser. But, because decryption takes time, a timestamp (validated on both sides) can indicate that the stream is a 'replay'.

Perhaps you could consider a longer timeout period for your company/application? Instead of a narrow window, you could realize some benefit by widening the window. This would have to be analyzed for its full impact on your systems, of course.

  • 2
    How could they decrypt the packets? I thought the point of a replay attack was that the data wasn't modified, it was just resent as-is to trigger the same operation again, because SSL is not decryptable for the forseeable future (i.e. the time decryption takes is long enough that synchronizing the clocks to around a couple billion years is enough to prevent decryption before the timestamp expires).
    – cpast
    Nov 13, 2014 at 17:31
  • @cpast I was kind of thinking the same thing. How susceptible are packets to being captured, and does this mean that it is reusable throughout the acceptable window?
    – mclark1129
    Nov 13, 2014 at 17:36
  • Even with inaccurate clocks, SSL cannot be replayed (because of the client_random and server_random values). Bad clocks may imply issues with certificate validation, though. Nov 13, 2014 at 17:38
  • @ThomasPornin I wasn't just thinking about SSL, but things like REST and authentication schemes where timestamps are useful for protecting against replay.
    – schroeder
    Nov 13, 2014 at 18:17
  • @cpast I might need to edit to show that modification is an option. As for SSL being secure, have you heard about POODLE?
    – schroeder
    Nov 13, 2014 at 18:21

You must log in to answer this question.

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