#23387: prop224: Time period desynch between client and service ------------------------------+-------------------------------- Reporter: asn | Owner: (none) Type: defect | Status: new Priority: High | Milestone: Tor: 0.3.2.x-final Component: Core Tor/Tor | Version: Severity: Normal | Keywords: prop224, tor-hs Actual Points: | Parent ID: Points: | Reviewer: Sponsor: | ------------------------------+-------------------------------- David found his client unable to connect to his service. Apparently, they compute different hsdir indices because the time period num is not synched: {{{ service side: Sep 01 12:36:59.000 [info] hs_get_responsible_hsdirs(): Finding responsible HSDirs for blinded key mCs1ObO+OmLpjYy36SWX3tv5rV9S2P6/BNo8rVjUy0g, time period number 17411 and for next period }}} {{{ client side: Sep 01 08:23:34.000 [info] hs_get_responsible_hsdirs: Finding responsible HSDirs for blinded key 3vsekKmh3WYjr85reqpS6Ts2xqJxSSgZHxgX/Jp1FK0, time period number 17410 and for current period }}}
Theory: We use `time(NULL)` as the time in `node_set_hsdir_index()` whereas we use the live consensus `valid-after` in `rotate_all_descriptors()`. This can cause desynch within the same tor instance. We should probably use the live consensus `valid-after` in all cases to have a common point of reference, and avoid problems with clock skews. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23387> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs