[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5506 [Tor]: Do we just keep downloading a consensus if our clock is wrong?
#5506: Do we just keep downloading a consensus if our clock is wrong?
------------------------+---------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: tor-client | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by sysrqb):
Replying to [comment:1 arma]:
> I'm not actually sure what we should *do* in these cases. We don't want
to just quit fetching, because then a jerk can give us a wrong consensus
and we'll freeze in place. Some sort of "if the one we just got is the
same as the one we already had, stop resetting
time_to_download_next_consensus[i]" logic might be a good start.
We can add this catch during networkstatus_set_current_consensus. We
already check if the digest of the current and digest of the fetched are
the same, so a flag can be flipped there.
> Another approach might be to reset time_to_download_next_consensus[i] if
!c but be more lenient if the one we have is merely wrong. (Wrong like the
consensus is from the future, I mean -- if the consensus is expired we
need another one rsn.)
And by more lenient you mean that we should provide some flexibility +/-
around the valid-after/valid-until times?
On a slightly different note, and possibly requiring a new ticket, is
there a reason we don't try to learn the current clock skew based on the
statuses we receive and connections we make? We determine our potential
skew and possibly print out warnings, but then we throw that info away.
We're always left assuming our clock is correct and not knowing how it
compares to the rest of the network. If we kept an average/"probable" skew
based on what we've seen, we may be able to handle a malicious consensus
more wisely. (and I just realized this directly relates to #2628)
Back to this issue, I think that if we either live in the past or the
future based on arma's comments we can check if we've already been
here/done this. When we know the clock skew we can assume that if every
consensus we fetch must have a valid-after date that is monotonically
increasing from the current one (and valid-after < fresh-until < valid-
until, of course), then we should be able to trust them (assuming sigs,
digests, etc check out). However, a side effect of this is that we will
need to track the last time we successfully fetched and accepted a
consensus and only refetch after (now + (fresh-until - valid-after)) until
we decide we're living in the present (for whatever reason: receive a
consensus that tells us we're actually correct or the clock is set
correctly).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5506#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs