[tor-bugs] #9001 [Tor]: Slow Guard Discovery of Hidden Services and Clients

[Tor Bug Tracker & Wiki]

#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