Re: [tor-bugs] #13664 [Tor]: Potential issue with rend cache object when intro points falls to 0.

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

#13664: Potential issue with rend cache object when intro points falls to 0.
-------------------------+---------------------------------
     Reporter:  dgoulet  |      Owner:
         Type:  defect   |     Status:  needs_review
     Priority:  normal   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  tor-hs 025-backport
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+---------------------------------

Comment (by dgoulet):

 Looking more in depth, this is caused by multiple issues that are here:
 #13698, #13699

 I'm still going to answer @asn questions but this bug probably will be
 resolved by the above.

 > a) This behavior only triggers when all the IPs are down or found
 unreachable, right?

 Bug #13698 explain how the intro points are flagged unreachable but it's
 actually really wrong.

 > b) How does Tor finally escape this loop in the current codebase? Since
 no IPs are reachable and no new descriptor can be fetched?

 That I haven't quite fully figure out yet. One possibility is that the
 rend cache object times out after {{{REND_CACHE_MAX_AGE (2*24*60*60)}}}
 but that's way too long for a client to not being able to reach an HS
 without having a lot of people scream on IRC/email.

 Second thing I can observed is that before all the intro points are
 removed from the cache, some actually succeed! So the next connection
 looks like it uses that circuit.

 However when that circuit closes, I think all bets are off as far as I can
 tell meaning the specific HS will not be reachable until the cache object
 is removed and a new one is fetched.

 {{{
 Nov 07 10:45:40.000 [info] pathbias_count_use_attempt(): Used circuit 48
 is already in path state use succeeded. Circuit is a Hidden service
 client: Active rendezvous point currently open.
 }}}

 > c) IIUC, the desc in if (e && !strcmp(desc, e->desc)) { is the whole
 descriptor as a string. So if that check succeeds, we already have the
 exact same descriptor? How would it help if we kept that same descriptor,
 since all the IPs listed in there are apparently unreachable? Would it
 just try to reconnect to one of those IPs, in case the connection
 succeeds?

 The problem is that we refetch the descriptor, parse all the intro points
 and at the end we just look if the {{{desc}}} is the same and bail out if
 yes. Thus the object becomes useless even if the current code realize that
 the intro points are empty. You can see this behaviour in
 {{{rend_cache_store_v2_desc_as_client()}}}

 FYI, that's now bug #13699.


 Also, thanks for the code style pointers!

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