[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:                    
---------------------------------------------+------------------------------
Changes (by mikeperry):

 * cc: andrea (added)


Old description:

> 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.

New description:

 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 repeatedly destroying HSdir
 lookup circuits for your target hidden service.

 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 leaning 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#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online