Opened 16 years ago

Last modified 8 years ago

#114 closed defect (Fixed)

hidden service descriptors quietly rejected when clock skewed

Reported by: arma Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Mar 29 06:47:33.643 [warn] rend_cache_store(): Service descriptor h7dkd7zc7aeplgy4 is too far in the future

When clients publish hidden services but their clock is wrong, the hidden service doesn't work. There might
be a log entry explaining this, but perhaps the log entry doesn't say enough? In any case, a log entry may
not be enough to let the user know, if he never looks at his logs.

Is there a better way to communicate this to the user, or is there some way we can cope anyway? (E.g. be more
forgiving about clock skew wrt hidden service descriptors (easy) or remember our skew based on dirserver
timestamps and have Tor "fix" outgoing published timestamps (foolishly hard))

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (3)

comment:1 Changed 16 years ago by nickm

Let's think about what we're using these timestamps for. There are two applications I can see:

  1. At the dirserv: we want to make sure that we have the most recent descriptor there is. In this case, we don't care whether it comes from the future or the past--so long as the user's computer doesn't hop around in time too much, newer is better.
  1. At the client ("Alice"): we don't want to become distinguishable by having the directory or someone impersonating it dole out very-obsolete descriptors; if the descriptor is pretty fresh, we can hope that there aren't too many versions of it. But this is only a hope: if "Bob" is hostile, there could be many descriptors in circuilation, and he could change them frequently to isolate people who d/l'd his descriptor at any given time.

But partitioning isn't (compared to the attacks you can do anyway) such a win against Tor as against (say)
minion. How could these attacks actually be used to hurt *Alice*? A hostile Bob will only choose intro
points he controls anyway, so all descs will be poor choices--I don't see how partitioning helps him. A hostile
dirserv will choose whichever descriptors have intro points he controls. This might be a problem, but skew doesn't
solve it very well.

So I don't think that relaxing the max-skew would be a big problem, but we should probably add better means to
make sure that users get good warnings when publishing skewed descriptors. (Yeah, some people will never check
their logs, but their controllers could help them out, and anyway we shouldn't gear everything towards helping
users who can't take help.

Also, the "warn-if-more-skewed-than-this" number should be less than the "maximum-skew" number.

comment:2 Changed 16 years ago by nickm

flyspray2trac: bug closed.

comment:3 Changed 8 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.