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