#25347: Tor stops building circuits, and doesn't start when it has enough
directory
information
-------------------------------------------------+-------------------------
Reporter: teor | Owner: asn
Type: defect | Status:
| needs_revision
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.0.6
Severity: Normal | Resolution:
Keywords: 031-backport, 032-backport, | Actual Points:
033-must, tor-guard, tor-client, tbb- |
usability-website, tbb-needs, |
033-triage-20180320, 033-included-20180320 |
Parent ID: #21969 | Points: 1
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by mikeperry):
Replying to [comment:28 asn]:
> Replying to [comment:25 mikeperry]:
> > A couple comments here:
> >
> > 1. We already treat non-destroy failures at the guard as rotate-away
failures in circuit_build_failed(). Note that there is an explicit check
to not blame the guard if circ->base_.received_destroy is set. If we
remove that check in circuit_build_failed(), we should not need asn's
patch, as the behavior would then be equivalent (or actually a superset,
since it would cover all destroy reasons). (I think this is what arma
meant in his point H?). This would be a simpler patch.
> >
>
> Seems like a reasonable plan. Let's proceed like that.
Ok. Note that after talking to arma, I decided to file #25705. In that
refactor I could also fix this issue. I guess it depends on if we want to
backport that.
> > 2. Roger's point G is scary. I like the solution in E, though, and I
think it actually fixes G. I would implement E by setting an is_predicted
flag in circuit_predict_and_launch_new(), and then check that flag in
select_entry_guard_for_circuit() to completely ignore the is_reachable
status there if it is set. Then if any of those predicted circuits
succeed, entry_guards_node_success() will get called, which will clear the
is_uneachable flag and allow us to resume using the guard. For guards that
fail only a non-zero but small portion of their circuits, this should
allow us to keep using them rather than rotating away. I am a fan of this
plan, and could write a patch for it if we like it.
> >
>
> Hmm, I can see how the solution of E can help with G, by making Alice
try her primary guards more aggressively in cases of predicted circuits,
but if Alice is a busy hidden service (like Roger describes in E) most of
her circs are not gonna be predicted.
But a client/service will always keep building predicted circuits such
that it has 3 of each type available. This means even a busy hidden
service will keep making predicted circuits, which, any time they succeed,
will reset the fact that the guard is reachable for use by other circuits.
So, so long as some circuits are succeeding through that guard, the
service should keep going back to it fairly quickly.
> Furthermore, I wonder if it can completely address the problem in
actually ''mischievous'' scenarios, where the adversary overloads all 3
primary guards of Alice (targeting them using guard discovery attacks) to
make her switch to other guards in her sampled set.
This case is tricky. I am not sure what to do with predicted circuits if
all primary guards get into the unreachable state. One option is to toss a
coin and pick primary vs sampled for predicted circuits, if all primary
are down.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25347#comment:29>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
