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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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:19 arma]:
 > Taking a step back: is this design the right one to encourage client
 applications to use? Basically you are wanting to disable much of the
 client-side onion caching logic.
 >
 > Is there a better design, like noticing when your network connection has
 been broken, and flushing all the client-side state right then, and
 otherwise letting Tor do its thing?
 >
 > Or better, we could improve the client-side caching logic to be more
 robust to whatever network behavior you're seeing? It is silly for each
 client application to have to do this logic itself.

 Replying to [comment:23 arma]
 > Can we get a more concrete case here, for exactly what behavior goes
 wrong? "What you do, what you expect, what happens instead."
 >
 > Then we can try to reconstruct what was happening on each Tor side, and
 think about if there's something smarter Tor could do instead.

 Let me give you a bit more information about what we're trying to achieve.

 The scenario is a client connecting to a hidden service that's running on
 a mobile device. (The client may also be running on a mobile device, but
 that's not relevant.) The service may frequently lose network connectivity
 or switch between networks, and each time it does so, it picks new
 introduction points and publishes a new service descriptor.

 If the client has a cached descriptor for the service, it's likely to be
 stale, and any attempt to connect using the stale descriptor will fail.
 Eventually Tor will discard the failing descriptor and the client's next
 connection attempt will fetch a fresh descriptor.

 We're trying to skip the initial connection attempt using the cached
 descriptor because it's unlikely to succeed, and waiting for it to fail
 prevents us from connecting quickly. There are a few ways we could do
 that:

 * Client tells Tor not to use any cached descriptor that may already exist
 * Client tells Tor not to cache the descriptor after fetching it
 * Service indicates in its descriptor that the descriptor should not be
 cached

 Of these possibilities, the first one seems to be the easiest to deploy,
 as it requires minimal changes to the client-side code and no changes to
 the descriptor format.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18620#comment:26>
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