[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16387 [Core Tor/Tor]: Improve reachability of hidden services on mobile phones

#16387: Improve reachability of hidden services on mobile phones
--------------------------+------------------------------
 Reporter:  asn           |          Owner:
     Type:  enhancement   |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.2.???
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:  SponsorR-can
--------------------------+------------------------------

Comment (by timonh):

 I reran the test switching from wifi to mobile network on android. Looking
 at the log it seems that Tor retries on the intro points once but then
 decides to try other ones.
 See attachment torlog2.
 I'm using Tor 0.2.8 so
 [https://trac.torproject.org/projects/tor/ticket/8239 #8239] should be
 fixed and Tor should retry each intro point three times.

 Looking at the code (rend_consider_services_intro_points() in
 rendservice.c) the intro points to retry are determined by a call to
 remove_invalid_intro_points(). Then Tor will try to establish a circuit to
 them. But after that Tor will try other intro points if there aren't
 enough yet. So if the retry points fail Tor will choose other ones.
 The code to retry an introduction point three times is contained in
 remove_invalid_intro_points() using MAX_INTRO_POINT_CIRCUIT_RETRIES.
 So subsequent calls to remove_invalid_intro_points() will return an
 introduction point to retry up to three times.
 But a single call to rend_consider_services_intro_points() will only retry
 each introduction point once and then try others.
 Is this intended behavior?

 Replying to [comment:7 timonh]:
 > Another problem here is that a client, that has an old descriptor of a
 HS that chose new intro points and published a new descriptor in the
 meantime will try to reach the old intro points for a long time before
 trying to fetch the descriptor again. The old intro points don't notice
 that the circuit to the HS is broken because of the long TCP timeout.
 Therefore they acknowledge the RELAY_COMMAND_INTRODUCE1 cells of the
 client.

 Regarding this issue the idea came up that an intro point could wait for a
 INTRODUCE2_ACK from the HS before sending a INTRODUCE_ACK to the client.
 Then a client would notice that the HS didn't receive the
 RELAY_COMMAND_INTRODUCE2 cell using a timeout and wouldn't wait at the
 rendezvous point for a long time.
 I'm not sure which other implications the change would have.
 Another possibility would be to close ready rendezvous points earlier
 using a timeout and than fetch the descriptor again.

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