[tor-bugs] #16387 [Core Tor/Tor]: Improve reachability of hidden services on mobile phones
Tor Bug Tracker & Wiki
blackhole at torproject.org
Tue Jun 21 12:34:46 UTC 2016
#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
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
More information about the tor-bugs