Re: [TLS] Server time

[Hauke Mehrtens <[e-mail]>]

On 04/05/2015 12:10 AM, Jeffrey Walton wrote:
> On Sat, Apr 4, 2015 at 5:57 PM, Dave Garrett <[e-mail]> wrote:
>> ...
>>
>> Do a ping with a time request after authentication and it would be protected, measure latency, and easily provide precise remote time adjusted for response time. Might be overkill, though it'd be simple enough to add.
>>
> I think the problem here is channel setup will fail *if* the client's
> clock is wrong. The client will fail to validate the end-entity
> certificate due to problems with the notBefore and notAtfer (even
> though its correct). You won't have a channel to perform the ping.

If the client trusts the servers clock the notBefore and notAtfer check
is useless, because a bad server could change the time of the check to a
value where the certificate check is valid. If you take the time from
the same entity where you get your certificate to check from the time
check is useless.

There is a big problem with embedded devices, which do not have a real
time clock.

One solution would be that you burn a valid certificate or CA
certificate into a firmware and your device trusts this certificate
regardless of the validity period. And this server could be used to get
the time from. But wouldn't it be better to deign this as an extra
protocol on top of TLS/DTLS?

The German electronic identity card is unable to do any online checks
and does not have a real time clock. It stores the issue date of the
most recent certificate it saw and checks every other certificate if it
was at least valid at this date. (The certificates used there are
normally only valid for some days and there is no revocation mechanism)

> I like the idea of a field like ServerHello.time so the server can
> communicate its belief in time. A client can defer a simple failure
> based on time until key exchange completes. If key exchange completes
> successfully, then the client can decide if it wants to accept the
> server's view of time.

Adding such a field could also result in some stupid developers using
this field to check if the certificate is valid for every handshake.

> The functionality leads to other attack surfaces, like a rogue server
> rolling back its time and using compromised key. But I think that can
> be solved with a good degree of certainty using Guttmann's security
> diversification techniques.
> 
> Jeff