[tor-bugs] #23455 [Core Tor/Tor]: hs: hs_circuitmap_get_rend_circ_client_side() doesn't consider REND_JOINED purpose
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Sep 11 15:00:00 UTC 2017
#23455: hs: hs_circuitmap_get_rend_circ_client_side() doesn't consider REND_JOINED
purpose
------------------------------+-----------------------------------------
Reporter: dgoulet | Owner: dgoulet
Type: defect | Status: assigned
Priority: High | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-hs, tor-client, prop224
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+-----------------------------------------
It is possible that we get a `RENDEZVOUS2` cell from the service _before_
we get the `INTRODUCE_ACK` from the intro point. Which means that the rend
circuit at that point, when the ack is received, its purpose is set to
`CIRCUIT_PURPOSE_C_REND_JOINED` which
`hs_circuitmap_get_rend_circ_client_side()` doesn't consider.
Here is the dicy part. It actually turns out that the legacy system has
also this bug but was using `log_info()` instead of warn so it probably
went unnoticed.
In any cases, it doesn't matter much because once the ACK has been
received, it would only warn and then exit the function correctly by
closing the intro circuit and not doing more.
That being said, I think the fix here is to make
`hs_circuitmap_get_rend_circ_client_side()` consider REND_JOINED circuit
but we should simply ignore the returned rendezvous circuit if it has been
joined and warn if not so we can catch an issue like that in the future.
As for legacy, I propose we do not do anything because it's actually doing
the right thing in the end and the log info doesn't alarm any user.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23455>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list