[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