[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:
--------------------------+------------------------------------
Comment (by cypherpunks):
I would suggest that the issue is that after the intro point sends the
ACK, something goes wrong such that the HS does not establish a circuit to
the RP. There are two possible "server-side" reasons for this:
1. that the intro point fails to tell the HS to connect to the RP, because
either (a) the circuit between the HS and the intro point is not working
or (b) the intro point is misbehaving due to a bug or malice.
2. that the HS fails to extend the circuit to the RP, because either (a)
the HS cannot extend a circuit to the RP because it is somehow resource-
bound or limited, (b) the HS cannot extend a circuit to the RP because it
cannot establish new TCP connections to its designated guards, or (c) the
HS is misbehaving due to a bug or malice.
I would suggest that (2) is unlikely, since fetching a new HS descriptor
usually solves the problem for the client, although it is not
inconceivable.
Approaches (a) and (b) described by [comment:17 dgoulet] might offer some
relief at the margins, particularly if the misbehaviour is amplified by
CPU load or network load, but I would like to suggest that [comment:18
asn] is right that they do not address either of the two possible
underlying "server-side" problems.
Approaches (a) and (b) also not fully address the "client-side" problem,
which is generally resolved by trying new intro points. Ideally, part of
the solution from the client's perspective would involve fetching the HS
descriptor again, even if only once per stream.
'''Proposal A.''' I would like to propose that a client facing this
behaviour should require some kind of verification from the intro point
that it has received confirmation from the HS that it has received the
instruction to extend to the RP (preferably signed by the HS) or even that
it has successfully extended to the RP (preferably signed by the RP and
the HS). The client would not need to wait for this confirmation to
establish a circuit to the RP. If the client does not receive that
confirmation within some designated period of time, then it would close
its circuit to the intro point, close its circuit to the RP, and remove
the intro point from its list to try. I believe that this would be enough
to trigger the client to fetch the descriptor if needed.
'''Proposal B.''' A "quick and dirty" client-side solution might have the
client just maintain a pointer to the intro point the data structure for
its circuit to the RP, and remove that intro point from its list whenever
the circuit to the RP is killed in state 11. This would not be elegant
and might have some false positives, although I think it would do the job.
Of course we should solve the "server-side" problem as well. I think that
if we start with Proposal A, then we will also have a way to
systematically debug the "server-side" issue.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25882#comment:20>
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