[tor-bugs] #18620 [Core Tor/Tor]: HSFORGET command to clear cached client state for a HS

[Tor Bug Tracker & Wiki]

#18620: HSFORGET command to clear cached client state for a HS
-------------------------------------------------+-------------------------
 Reporter:  str4d                                |          Owner:  str4d
     Type:  enhancement                          |         Status:
 Priority:  Medium                               |  needs_revision
Component:  Core Tor/Tor                         |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.9.x-final
 Keywords:  tor-hs, 029-accepted, review-        |        Version:  Tor:
  group-3                                        |  0.2.7.6
Parent ID:                                       |     Resolution:
 Reviewer:  asn, special                         |  Actual Points:
                                                 |         Points:  1
                                                 |        Sponsor:
                                                 |  SponsorR-can
-------------------------------------------------+-------------------------

Comment (by asn):

 Replying to [comment:29 akwizgran]:
 > Replying to [comment:28 timonh]:
 > > Replying to [comment:27 akwizgran]:
 > > > I'm not sure whether a solution to #19522 would necessarily fix this
 issue. We need to consider not just situations where the service's network
 interface is down, but also situations where one interface goes down and
 another comes up (for example, switching from mobile data to wifi). In
 that case the service can create a new set of introduction point circuits
 and publish a new descriptor via the new network interface while the old
 interface remains down, so returning to the old circuits when the old
 interface comes back up would not solve the problem.
 > >
 > > I discovered #19522 with Tor on Android switching from wifi to mobile
 data. See [https://trac.torproject.org/projects/tor/ticket/16387#comment:7
 #16387#comment:7].
 > > I noticed that Android kills all open connections when the network
 interface gets switched.
 > > Without #19522 the descriptor won't change because Tor would reconnect
 to the intro points.
 > > On which platform did you notice the behavior you describe?
 >
 >
 > I'm also talking about Android. I think this ticket and #19522 both
 relate to the same underlying problem, i.e. the service loses its intro
 circuits when the network interface goes down and chooses new intro points
 when Tor reconnects. But the discussion on #19522 seems to assume that
 there's a single network interface, so we can wait for that interface to
 come back up and then build new circuits to the old intro points. I'm not
 sure that's a correct description of the situation on Android.
 >
 > When an Android device switches between mobile data and wifi, it's my
 understanding that one network interface is taken down and another is
 brought up. I don't know if Tor can detect these changes in a cross-
 platform way, or whether it can tell that the old and new network
 interfaces are somehow equivalent, such that intro points from the old
 interface should be reused with the new interface. That's why I said above
 that I'm not sure whether a solution to #19522 would resolve this ticket -
 it would really depend on how the solution was implemented.
 >
 > If we can find a solution to #19522 that builds new circuits to the old
 intro points via the new network interface then this ticket will be
 redundant. But if we don't have a clear path to achieving such a solution
 then I'd prefer to continue with this ticket, as we know it solves the
 problem for our use case.

 The patch in #19522 does not care about network interfaces. It's just more
 stubborn in sticking with old intro points when there are local network
 issues. So it will wait till the network is back up (in whichever
 interface), and then will try to reestablish the same intro points.

 The patch in that ticket could benefit from some more testing by people
 who use HSes on mobile phones, so that we get more confidence that it
 works well.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18620#comment:30>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online