[tor-bugs] #3652 [Tor Client]: Export clock skew opinion as getinfo command

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Wed Aug 24 05:37:26 UTC 2011


#3652: Export clock skew opinion as getinfo command
-------------------------+--------------------------------------------------
 Reporter:  mikeperry    |          Owner:  nickm             
     Type:  enhancement  |         Status:  assigned          
 Priority:  major        |      Milestone:  Tor: 0.2.3.x-final
Component:  Tor Client   |        Version:                    
 Keywords:               |         Parent:                    
   Points:               |   Actualpoints:                    
-------------------------+--------------------------------------------------

Comment(by mikeperry):

 Replying to [comment:8 rransom]:
 > Replying to [comment:6 mikeperry]:
 > > Replying to [comment:4 nickm]:
 > > > I started doing some work here in a branch called "skew_estimate".
 Needs some attention and review for sanity.
 > >
 > > In command_process_netinfo_cell(), why do you only set apparent_skew
 if conn->handshake_state->sent_versions_at was within 180 seconds? Is it
 possible that the dirauth just won't respond in any reasonable amount of
 time here?
 >
 > The SSL handshake itself is our only assurance that we are actually
 talking to the server we think we are talking to in something like 'real
 time'.  After the handshake completes, an active attacker can delay the
 NETINFO and VERSIONS cells for arbitrarily long periods of time.  We
 should probably decrease the 180-second window to around 30 seconds or
 less.

 Hrmm, effectively fingerprinting the user. Very nice. I didn't see that.
 There should definitely be a comment on this line then. If you and nick
 had died before this merged, I might have removed that check. A future me
 might still try to remove it :).

 I agree that it should be lowered, but I think we should use the circuit
 build timeout (perhaps div 3) to give us a floor for the value. 30s might
 be too low of a value on a satellite connection or protest-laden link.

 > > In router_set_networkstatus_v2() and
 networkstatus_set_current_consensus(), you use the published/valid_after
 time. This is probably too low of a resolution to bother to record it to
 report for TBB. We care about precision down to the second (possibly even
 sub-second)... Recording this value will just cause all TBB users to all
 have weird, messed up clocks. If we want that property, we can get it
 other ways than through the control port command...
 >
 > The timestamp on a published consensus is only used as a lower bound on
 the current time.  Tor reports this timestamp to its clock skew reporting
 system so that it can complain if the system clock is ''definitely''
 skewed.

 I uh, failed to substract these two checks properly I guess ;). I didn't
 realize they were updating only in the case of the documents being from
 the future.. At the risk of asking another dumb question now, why 60s for
 the consensus but a whole day for the ns2 documents? Also, why 60s? Isn't
 any amount of time in the future evidence of drift?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3652#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list