Slow Guard Discovery of Hidden Services and Clients
|Reported by:||mikeperry||Owned by:|
|Component:||Core Tor/Tor||Version:||Tor: 0.2.7|
|Severity:||Normal||Keywords:||tor-hs, path-bias, needs-proposal, mike-can, prop259, tor-guard, tor-03-unspecified-201612|
|Cc:||rpw, nickm, arma, sysrqb, asn, andrea, dave2008713@…, special||Actual Points:|
Description (last modified by mikeperry)
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:
- Multiple layers of guard nodes.
- 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.
- 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.
Change History (34)
comment:11 Changed 3 years ago by nickm
- Milestone changed from Tor: 0.2.5.x-final to Tor: 0.2.6.x-final
comment:17 Changed 2 years ago by isabela
- Keywords SponsorR added
- Points set to large
- Version set to Tor: 0.2.7
comment:20 Changed 20 months ago by nickm
- Milestone changed from Tor: 0.2.7.x-final to Tor: 0.2.8.x-final
comment:21 Changed 19 months ago by mikeperry
- Keywords 028-triage added
comment:23 Changed 19 months ago by dgoulet
- Keywords SponsorR removed
- Sponsor changed from SponsorU to SponsorR
comment:27 Changed 14 months ago by dgoulet
- Milestone changed from Tor: 0.2.8.x-final to Tor: 0.2.9.x-final
comment:28 Changed 13 months ago by dgoulet
- Keywords 028-triage removed
- Sponsor changed from SponsorR to SponsorR-can
comment:31 Changed 13 months ago by isabela
- Milestone changed from Tor: 0.2.9.x-final to Tor: 0.2.???