[tor-bugs] #23387 [Core Tor/Tor]: prop224: Time period desynch between client and service

[Tor Bug Tracker & Wiki]

#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