[tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state

[Tor Bug Tracker & Wiki]

#24469: Cannibalizing a circuit should check that first hop is in our guard state
--------------------------+------------------------------------
 Reporter:  dgoulet       |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-circuit   |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------
Description changed by dgoulet:

Old description:

> I noticed this on my v3 hidden service info logs which happened on Nov
> 22nd:
>
> {{{
> Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last
> hop ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
> $77159B89F39708B27CAC528FF32DD786569A11A5(open)
> $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
> $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
> Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
> circuit_send_next_onion_skin() failed.
> Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin)
> failed.
> Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
> Closing.
> }}}
>
> So that circuit ^ has a Guard
> (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or
> so before:
>
> {{{
> Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
> Removing sampled guard lovejoy
> ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
> ago, and confirmed over 60 days ago.
> }}}
>
> Turns out that the circuit was cannibalized but tor made it failed
> because I assume our guard state wasn't available for that circuit which
> ultimately triggered those warnings. asn informed me that it is important
> that the circuit with old guard(s) stay alive for a while to help
> mitigate Guard discovery attacks.
>
> Bottom line, I think our cannibalized function should exclude any circuit
> that doesn't match our guard state. In the meantime, those warnings will
> appear in the logs.

New description:

 I noticed this on my v3 hidden service info logs which happened on Nov
 22nd:

 {{{
 Nov 22 20:04:24.000 [info] internal (high-uptime) circ (length 4, last hop
 ThomasBernhardsHose): $175921396C7C426309AB03775A9930B6F611F794(open)
 $77159B89F39708B27CAC528FF32DD786569A11A5(open)
 $EE2D39A31F09EDD15B887B6EE7AB1396E52C3730(open)
 $A40E1C039224FA8072C7C84F729236FD738C69DA(open)
 Nov 22 20:04:24.000 [info] connection_edge_process_relay_cell():
 circuit_send_next_onion_skin() failed.
 Nov 22 20:04:24.000 [warn] connection_edge_process_relay_cell (at origin)
 failed.
 Nov 22 20:04:24.000 [warn] circuit_receive_relay_cell (backward) failed.
 Closing.
 }}}

 So that circuit above has a Guard
 (`175921396C7C426309AB03775A9930B6F611F794`) that was removed a minute or
 so before:

 {{{
 Nov 22 20:03:39.000 [info] sampled_guards_update_from_consensus():
 Removing sampled guard lovejoy
 ($175921396C7C426309AB03775A9930B6F611F794): it was sampled over 120 days
 ago, and confirmed over 60 days ago.
 }}}

 Turns out that the circuit was cannibalized but tor made it failed because
 I assume our guard state wasn't available for that circuit which
 ultimately triggered those warnings. asn informed me that it is important
 that the circuit with old guard(s) stay alive for a while to help mitigate
 Guard discovery attacks.

 Bottom line, I think our cannibalized function should exclude any circuit
 that doesn't match our guard state. In the meantime, those warnings will
 appear in the logs.

--

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