[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 asn):
Replying to [comment:5 timonh]:
> I recently analyzed the behavior of Hidden Services (HS) when their IP
address changes and identified the following problems.
>
Hello timonh! Thanks for doing this analysis!
I don't know much about mobile networking and programming, but it's
definitely something we need to improve ASAP, so any pointers/feedback is
welcome!
> 1. A client connected to a HS doesn't notice, that the established
circuit is broken when the HS changes it's address. This happens because
the circuit won't be closed until the entry guard of the HS detects a TCP
timeout and sends a destroy cell down the circuit. The problem can be
handled by the application itself by using own acknowledgments and closing
the circuit when it detects a timeout. The circuit can be closed by using
the Tor Control Protocol (use GETINFO stream-status to find the id and
CLOSECIRCUIT to close it).
>
> 2. A HS has to notice, that it's own connections are broken after an IP
address change so it can reestablish circuits to the introduction points.
On linux this lasts until TCP reports a timeout which can take quite long.
On Android connections get killed by the OS when an interface changes.
>
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.
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?
> 3. On Android I noticed, that an HS chose new introduction points after
an IP change because Tor thought they were down. The issue seems to be
addressed here: [https://trac.torproject.org/projects/tor/ticket/8239
#8239].
>
This should be fixed now.
> 4. Another related problem is described in:
[https://trac.torproject.org/projects/tor/ticket/16966 #16966]. It may
result in a 5 minutes waiting time when a HS reuses it's introduction
points after a downtime.
>
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?
> Any other opinions on how these problems can be solved?
>
> I'm currently working on [https://github.com/kit-tm/PTP] and therefore
interested in making Hidden Services work smooth on mobile devices
(particularly Android).
Interesting project :) Best of luck and keep in touch! You might also want
to join our IRC channels on OFTC (#tor-dev).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16387#comment:6>
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