[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:                    
---------------------------------------------+------------------------------
 In http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf, one of the
 attacks described is a method for locating the Guard nodes of a hidden
 service within about an hour.

 It also seems possible to locate the Guard nodes of persistent, automated
 clients in a similar timeframe by similarly fingerprinting and destroying
 HSdir lookup circuits.

 These attacks are possible to execute on such rapid timescales because
 *each* endpoint in hidden service communications can destroy the current
 circuit, and force the other party to create a new one using a new middle
 node.

 There are at least three ways to slow this attack:

  1. Multiple layers of guard nodes.
  1. Create a "Virtual Circuit" abstraction layer that picks your hops for
 a given purpose, and tries to re-use those hops even after certain failure
 conditions.
  1. Change the Tor Protocol to prevent DESTROY cells and other mechanisms
 of circuit destruction from destroying the counter-party's endpoint, and
 create mechanisms for multiple clients to share a single HS rend circuit
 (such as I2Ps 'garlic routing' concept).

 Nick and I are tentatively learning towards the "Virtual Circuit"
 approach. Such a layer would cleanly decouple path selection from circuit
 use, and allow us to do things like keep the same three hops for rend and
 intro circuits for N days, regardless of transient circuit failures or
 DESTROY cells.

 This would considerably slow the attack, and also make all sorts of
 anonymity metrics and analysis easier to do. For example: We can choose N
 intelligently such that we would expect the runtime of the attack to be a
 function of our guard lifetime from #8240, or we could define lifetime
 based on expected circuit use and application-provided linkability hints
 (such as #5752).

 We can also use the layer to improve the path bias accounting to only
 count failure if you are forced to choose a new path, rather than simply
 make a new circuit.

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