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:  needs_revision
 Priority:  High             |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor     |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  tor-hs, prop224  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------
Changes (by dgoulet):

 * status:  needs_information => needs_revision
 * milestone:  Tor: 0.3.2.x-final => Tor: 0.3.3.x-final


Comment:

 Replying to [comment:6 asn]:
 > BTW here is an example of a thing that might go bad (and the suggested
 tests above would not catch):
 >
 > `get_voting_interval()` and `hs_get_time_period_num()` and
 `hs_in_period_between_tp_and_srv()` all use
 `networkstatus_get_live_consensus()` and are used both by clients and
 services in multiple places. If a live consensus is not found those
 functions have an alternative behavior, and if we do the suggested change
 here we could be using this alternative behavior more frequently. We
 should make sure that this won't cause any reachability issues.

 Good points!

 I've did an investigation and shared random is the problem. We kind of
 bound tightly the HS and SR subsystems with those functions. Dirauth MUST
 use the live consensus for their computation of intervals and time period
 so we can't change `get_voting_interval()` to use "latest consensus". It
 could have consequences on the SR (maybe although I really wonder if a
 dirauth can operate without a live consensus...)

 To pull this off, we would need a function from which we can control which
 `ns` object we pass to the series of functions that we need in the HS
 subsystem from the SR subsystem or tell the function that we do not care
 about live.

 For `hs_get_time_period_num()`, it is OK to stay like this using a live
 consensus because that function returns the time period tor thinks it is
 in and it should be either a live consensus or just wing it with the
 current time which is what we want if we have no live but we'll still try
 to reach the HS.

 For the service, it ONLY uploads descriptors if it has a live consensus,
 this is enforced in `should_service_upload_descriptor()` so no way to go
 around. It means that once a client gets a descriptor, it is for sure a
 live consensus that the service has.

 That being said:

 * `hs_in_period_between_tp_and_srv()` is only used by the service so that
 is fine to keep using live consensus requirement.

 * The problem, as you pointed it out, is the use of the functions from the
 SR subsystem that we can't change that requirement.

 In conclusion, we need a set of functions that do not require a live
 consensus that only the HS client would use where the SR would use
 something else that requires the live consensus.

 I'm unsure about 032 for this. I think we might be OK to postpone this
 until we get a sense of what is the impact on reachability/usablility and
 who knows, maybe 99.9% of tor clients work with a live consensus and maybe
 it is probably good for them to wait for it.

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