[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24469 [Core Tor/Tor]: Cannibalizing a circuit should check that first hop is in our guard state
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs