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

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

#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):

 Replying to [comment:6 asn]:
 > Hm, I feel the two points above are connected. For example, if the
 client realizes that the rend circuit is broken '''before''' the HS
 reestablishes its intro circuits, then the client will try to introduce
 herself to a broken intro point. That's no good.
 >
 > Since the client has to reintroduce herself when a rend circuit dies
 (right?), it probably makes sense to have the HS reestablish intro
 circuits as fast as possible.
 >

 I totally agree with you on that. If the HS reestablishes it's intro
 circuits fast clients can just reconnect after they noticed a timeout
 without the need to fetch a new descriptor.

 > On this topic, you mentioned that in Android connections get killed when
 the interface changes; do you think this behavior is something we could
 use? Or maybe Tor already uses this behavior implicitly, since it will
 notice the killed connections and try to reestablish its intro circuits?
 Can we do better here?
 >

 The behavior of Android is good for us in the sense that we don't have to
 wait for the long TCP timeout as on Linux. I could confirm, that Tor 0.2.8
 notices that the circuits are broken after an IP change and tries to
 reestablish the intro circuits. But it seems that when I switch from wifi
 to mobile network Tor tries to reconnect too early when the interface
 isn't up yet and therefore thinks the intro points aren't reachable
 anymore. This results in Tor choosing new intro points.
 I attached the interesting part of the log. Looking at the log Tor notices
 that the network is unreachable but draws the wrong conclusion from it
 (intro point isn't reachable anymore).

 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.

 > Looking at the ticket, this seems like something we will fix as part of
 "next gen hidden services" (proposal 224). Does this happen frequently
 enough for you, that we should consider baking it into the current system
 as well?
 >

 I haven't noticed the problem during my tests yet. Is there a schedule
 when proposal 224 will be implemented/released?

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