[tor-bugs] #5506 [Tor]: Do we just keep downloading a consensus if our clock is wrong?

[Tor Bug Tracker & Wiki]

#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