Time synchronization issues

Nick Mathewson nickm at alum.mit.edu
Tue Oct 21 20:55:19 UTC 2003


On Tue, 2003-10-21 at 04:30, Roger Dingledine wrote:
 [...]
> What's the right answer to this? Currently I've got a patch to tortls.c
> which slides "now" back and forth a couple hundred seconds in between
> calls to things like X509_cmp_time(X509_get_notBefore(cert), &now),
> to handle some minor slop.

This is a good solution. 30 minutes seems like plenty.

> But what about major slop? Like, one of our servers had his clock several
> hours off, today, and he wasn't allowed to connect to the network. His
> original descriptor is still being considered "newest" by the dirservers:
> they're rejecting all his updates because they're older (now that he's
> fixed his clock).

Hm.  Dirservers should reject all descriptors more than a little bit in
the future.

> Will the world end if we tolerate certificates that are wrong by, say,
> a whole day? What do other systems do here? What's the point of the
> timestamp checking on the certs, in terms of our threat model?

Risks:  We want certs to expire so that private keys can expire.  If we
never reject very-old certs, an attacker can compromise an arbitrarily
old key and impersonate an OR.

OTOH, the only reason I can think to reject _future_ certs in order to
prevent exactly the current situation: If an OR has a clock skewed N
days into the future, and we don't reject future certs, then (A) the
attacker gets an additional N-day window to exploit key compromise, and
(B) the skewed OR will reject other certs, thinking that those certs
have long since expired.

> And the broader question: when we are unhappy at a TLS peer and hang
> up on him, he has no idea why we hung up. It occurs to me that we've
> already handshaked by this point, so we could send a "failed" cell with
> a payload which describes why we're hanging up on him. Is this a good
> idea or a bad idea?

If it's an OR-OR connection, both of you have certs, so both of you can
realize that there's skew so long as your criteria are symmetric.

If it's an OP connection, the OP will notice skew and hang up.

The important thing is that the error messages need to suggest clock
skew as a possibility instead of a bad cert.
-N



More information about the tor-dev mailing list