[tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:  dgoulet
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:  #22455        |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Changes (by dgoulet):

 * cc: dgoulet (removed)


Comment:

 Looking at `debug.A.log`, what I see is happening is:

 1. Client opens a rendezvous circuit.
 2. Client opens an intro circuit.
 3. Client establishes both and waits for the intro ACK.
 4. Client gets the intro ACK, closes that circuit.
 5. Client waits 2 seconds, considers the RP circuit expired and close it.
 6. Repeat (1).

 Rinse and repeat non stop. So the same intro point being picked is normal
 because it is the only one that is working and doesn't time out/fail.
 Note, there might be other bugs but this is my initial observation.

 Overall, the rendezvous circuit ends up in
 `CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED` state but then we don't apply a
 very long cutoff when evaluating to expire the circuit. Considering a
 service under heavy load, we should expand that cutoff way more so we
 leave a bit of time for the service to reach us?

 Downside, the service might just be ignoring the client because it might
 have launched too many rendezvous circuits or is out of memory. We don't
 have an ACK that is sent from service to intro point to inform the client
 that "yes we are about to launch the RP circuit so please be patient".

 I think, there are couple things we might want to consider.

 a. Extend the time out cutoff of an established waiting for service
 rendezvous circuit client side
 (`CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED`) so we give a bit of room to
 the service to communicate. 2 seconds timeout (in this case) is imo very
 short especially considering a popular service...

 b. Some sort of upper threshold on how many connection attempts we do to a
 service before we stop trying. For instance, we could consider that after
 3 back and forth, we stop trying and close the SOCKS connection with an
 "Unable to connect" kind of error.

  Right now, it will do the above dance for 120 seconds (the SOCKS port
 default timeout) so it puts pressure on the network where we could have
 stopped at 3 attempts before..

 I personally think we should maybe aim for a combination of (a) and (b).

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