Re: [tor-bugs] #23764 [Core Tor/Tor]: hs-v3: No live consensus on client with a bridge

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#23764: hs-v3: No live consensus on client with a bridge
-------------------------------------------------+-------------------------
 Reporter:  dgoulet                              |          Owner:  dgoulet
     Type:  defect                               |         Status:  new
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, prop224,                     |  Actual Points:
  034-triage-20180328, 034-removed-20180328      |
Parent ID:  #23605                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 Replying to [comment:13 dgoulet]:
 > I'm gonna go on a limb here and say that this is a bit "out of scope" in
 some ways or just too complicated for s8 at this stage.

 I agree, I don't think we can get this done in a few weeks, but we should
 do it eventually. Because Tor clients can now bootstrap and use exits with
 a reasonably live consensus (or skewed clock), but they can't use v3 onion
 services.

 > I've gone over the thread above (which is kind of old, things have
 changed a bit since then) and what I can say is that the changes would
 need to happen in many places and thus require us to expand considerably
 our reachability unit testing.
 >
 > First in `can_client_refetch_desc()` to let the client try to download a
 descriptor without a live consensus.
 >
 > The second big part would be in `hs_get_responsible_hsdirs()` which also
 requires a live consensus but also used by the service ... so some split
 to be done.

 No, services should also work with a reasonably live consensus. Otherwise,
 people running services on small devices with skewed clocks will be sad.

 > Then finaly, make `hs_get_time_period_num()` maybe fallback on the
 "latest consensus" instead of `approx_time()` if the live consensus can't
 be found. The idea here is that for the whole subsystem the same time
 source has to be used. So having code path that use the "latest consensus
 valid_after" time with approx_time is a recipe for reachability issue.
 >
 > We had so many issues with timing over the years and ended up realizing
 that whatever we use, the entire subsystem needs to use the same time
 source. In theory, right now, the "live consensus valid_after" should be
 used across the board. Part of my thinks we would benefit from a "HS time
 source" that is updated every time we get a new consensus and then the HS
 subsystem only uses.

 Sounds like we need a module that handles onion service time.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23764#comment:14>
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