Using the date from the server itself is self-defeating: a fake server could send a fake date.
Actually there is in SSL itself a field for the date: the first four bytes of the
server_random fields contain the current date and time, as known by the client and the server, respectively. This implies the following:
- A passive attacker, eavesdropping on the line, can detect clients whose clock is amiss.
- An active attacker, running a fake server, can know the client's date and time, down to a precision of 1 second.
The attack scenario here is an attacker who has stolen an server's private key. The certificate has been revoked; however, the attacker also obtained CA certificates and CRL which "proved" the certificate to be valid at various previous dates. The attacker, in position to do MitM, then runs a fake server and emulates the Internet at that time, in particular sending back to the client the past CRL bearing the date that the client believes to be current.
An out of date client may make connections fail in case their current date is too far in the past, or too far in the future. The normal recovery for that case is to complain to the user, so that he sets the date and time properly. On a pure theoretical basis, there cannot be any other method which always works against MitM attackers: such an attacker can, as I said, "emulate" an old version of the Internet (as a whole), thus preventing the device from obtaining the true current date or even noticing that its clock is not set properly.
You could try to obtain a time stamp from some Time Stamp Authority; however, this implies validating the TSA certificate, or, more accurately, assuming that the TSA private key has never been stolen. So, in practice, it is possible to make a reasonably strong guess of the current date and time in a way which attackers will find difficult to fool. But that's expensive (extra connections to TSA) and depends on these external TSA, who might not be free and/or might not agree with getting so many time stamp requests from your deployed devices.
Edit: if you do revocation checks with OCSP, and the client insists on including a nonce in the request, then you get (somehow) the same property as with the TSA -- with the same caveats: you still have to assume that some entity's key has not been stolen (TSA, OCSP responder, CA...), and you still need to do extra connections.