[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs