[tor-bugs] #15618 [Tor]: Tried to establish rendezvous on non-OR circuit with purpose Acting as rendevous (pending)

[Tor Bug Tracker & Wiki]

#15618: Tried to establish rendezvous on non-OR circuit with purpose Acting as
rendevous (pending)
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:  dgoulet
         Type:  defect   |     Status:  accepted
     Priority:  normal   |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  tor-hs, SponsorR, TorCore201509,
Actual Points:           |  PostFreeze027
       Points:           |  Parent ID:
-------------------------+-------------------------------------------------
Changes (by dgoulet):

 * keywords:  tor-hs, SponsorR, TorCore201508, PostFreeze027 => tor-hs,
     SponsorR, TorCore201509, PostFreeze027


Comment:

 Replying to [comment:5 asn]:
 > Looking at the code, clients send `ESTABLISH_RENDEZVOUS` cells in
 `rend_client_send_establish_rendezvous()` through
 `rend_client_rendcirc_has_opened()` which is calle only in
 `circuit_has_opened()`. Hence, from first glance there doesn't seem to be
 some sort of relaunch mechanism that would establish two rendezvous in the
 same circuit.
 >
 > Next step is to check if this can happen through cannibalization or
 something. Otherwise, it does seem like a misbehaving Tor client.

 I don't see anything in the cannibalization process that could trigger a
 client to choose a circuit with the purpose of
 `CIRCUIT_PURPOSE_C_ESTABLISH_REND`. The `circuit_find_to_cannibalize()`
 only returns general purpose circuit.

 I digged a bit here and what I think can *possibly* happen here (quite
 difficult to follow the code so somebody else should confirm) is that in
 `circuit_get_open_circ_or_launch()`, towards the end when we do open a new
 circuit with `circuit_launch_by_extend_info()`, if the circuit returned by
 this function happens to be open (`CIRCUIT_STATE_OPEN`), we call
 `circuit_has_opened()`. Also in `circuit_send_next_onion_skin()`, when the
 state of the circuit's cpath is `CPATH_STATE_OPEN`, we again call
 `circuit_has_opened()`.

 So, what could be happening (NOT 100% sure) is that we ask for a new
 circuit, it opens super fast where `circuit_send_next_onion_skin()` set
 the circuit state to open and then calls `circuit_has_opened()` and then
 following this it's called again in `circuit_get_open_circ_or_launch()`
 because the circuit we got in there is open. That can explain why this
 error is not at every establish rendezvous cell but just some of them in
 the network because it's a clear race condition if I'm right.

 Someone with *better* knowledge of circuit building should look at that in
 more depth though because I'm a bit unsure of the fix (if any...).

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