What role does clock synchronization play in SSL communcation
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.
- What role does clock synchronization play in SSL communications and what sorts of vulnerabilities does disabling it introduce?
- What is typically considered to be the maximum acceptable range for clock synchronization in secure customer facing applications?
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
notAfterfields; 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
thisUpdatefield that says when it was produced, and a
nextUpdatefield 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).
Certificate validation could be a problem for servers if client certificates are being used, but that isn't the common case.
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?
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.
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?