[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 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.

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