[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:
--------------------------+------------------------------------

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