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

[Tor Bug Tracker & Wiki]

#23764: hs-v3: No live consensus on client with a bridge
-----------------------------+------------------------------------
 Reporter:  dgoulet          |          Owner:  dgoulet
     Type:  defect           |         Status:  needs_information
 Priority:  High             |      Milestone:  Tor: 0.3.2.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:  accepted => needs_information


Comment:

 Replying to [comment:2 asn]:
 > Suggested fixes here:
 >
 > a) If you can't seem to get a '''live''' consensus from your bridge, but
 you can get a reasonably live one, then build circuit to fallback dirs and
 try to get a live consensus.

 Yes definitely but that is probably a more broader bug in tor itself and
 not HS. I'll investigate this a bit more and open a ticket for it. So not
 part of this fix.

 >
 > b) If we can't get a live consensus for a while, attempt to connect to
 v3 with reasonably live consensus. Or the opposite.

 Ok here is my thought on this. I think to simplify things, the HS client
 should always check for a reasonably live consensus and here is why.

 1) We have a live consensus, then
 `networkstatus_get_reasonably_live_consensus()` function returns it.

 2) We do not have a live consensus which means that tor is trying to
 download one.

 I see three scenarios that can lead to failures (and maybe more but my
 point will get clear with those):

  2.1) Client has a skewed clock so the consensus we'll receive is never
 live BUT chances are that the consensus it has is actually live.
  2.2) The dir cache/auth simply can't provide a newer one so no live.
  2.3) We are waiting to download a consensus because we've already tried
 many times and we are backing off for now. In other words, we are stalling
 a bit so no live.
  2.4) We wait for it but won't be sure to have a live one.

  In whatever case, we want to give a chance to the HS client and thus use
 a reasonably live if available. If we consider 2.4) to be enough for the
 client to stall and have a better chance to compute a hashring that at
 least one HSDir will workout.

 I'm unsure here, I think it would add much complexity to the code for
 checking if we have an inflight download consensus and when we might have
 failed already 2 times to fetch a live one so "ok let's use reasonably
 live".

 A reasonably live consensus is 24h maximum skew which I think is not often
 tor client will be stuck to use that since the bootstrap process is to
 download a consensus. And if for some reason the client doesn't think it
 is live, chances are that it is live or close to live. The only scenario I
 see where that might not be true is if the dirauth failed for many hours
 to create a consensus or the client can't reach dircache but then I
 believe the dirinfo also will not be enough to continue anyway.

 THAT being said with this WALL of text, here is my proposed fix: we use
 `networkstatus_get_latest_consensus()` which is btw what the
 `hs_get_responsible_hsdirs()` function uses.

 We get a consensus at bootstrap else we don't bootstrap. We'll never use a
 consensus that is older than 24h (reasonably live) and our dirinfo will
 never be usable if we have a too old consensus. So, lets just use the
 latest consensus we have which is basically the best effort of tor? And we
 know that the service will be accessible with a consensus up to 24h in the
 past because of this 24h overlap period.

 Fix is simple but many things need to change in the test to not MOCK the
 live consensus function. So before I do that, I would like a second
 opinion.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23764#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online