#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@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs