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