[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9001 [Tor]: Slow Guard Discovery of Hidden Services and Clients
#9001: Slow Guard Discovery of Hidden Services and Clients
---------------------------------------------+------------------------------
Reporter: mikeperry | Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.5.x-final
Component: Tor | Version:
Keywords: tor-hs path-bias needs-proposal | Parent:
Points: | Actualpoints:
---------------------------------------------+------------------------------
Comment(by mikeperry):
Replying to [comment:6 rransom]:
> The only solution is to add a second layer of guards (âidentity
guardsâ?), dependent on the client's âidentityâ (as determined by the same
things that control stream isolation).
I recognize that link failure might be one way to attack a virtual circuit
layer, but I don't believe it makes a secondary layer of guards the only
solution, and I don't believe that a well designed virtual circuit layer
would suffer as bad as you say under the timeout issues either.
> This fix has some prerequisites:
> * Tor relays must use a UDP-based link protocol exclusively, for
multiple security reasons. (Some entry nodes might allow their clients to
connect using other link protocols.)
> * Clients must be able to choose a set of identity guards
deterministically from a ''non-uniform'' (e.g. load-balanced) distribution
according to a seed (#2653 gives one approach).
> * Each client application must be associated with one or more
persistent identities. Otherwise, using identity guards only adds a
moderate delay in finding a client's entry guards.
I think what you allude to here in this third prerequisite point is
exactly why virtual circuits are better. My plan is to use virtual
circuits plus strong stream/identity isolation (#5752) to cause you to try
to use the same 3 hops for the same isolation, and to retry once you are
successful. Before you're successful, it doesn't matter so much against
this attack (because the other endpoint is not yet aware of your
connection attempt).
The most important thing is making it simple to reason about, and virtual
circuits are way easier to reason about than multiple layers of guard
nodes, because we've been pretending Torcircuits are more robust/permanent
than they are in all of the existing Tor analysis to date. A second layer
of guards changes the entire analysis of Tor.
> * In order to avoid linking a client's identities, Tor clients must not
allow any information about the Tor network or destination servers
obtained through one identity to affect any behaviour of its other
identities. (This requires that adaptive CBT and the path-bias detector
be removed, and that many client-side caches be isolated to a single
identity.)
I think once we get to this point, we've already realized that there are a
lot of hidden complexities and routing behavior changes we'll need to
support 2 layers of guards as opposed to virtual circuits.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9001#comment:7>
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