What role does clock synchronization play in SSL communcation

Question

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?

Answer 1

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).

Answer 2

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.