Mike Perry: > Roger Dingledine: > > http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf > > > But actually, this Oakland paper you're looking at is a mash-up of two > > paper ideas. The first explores how to become an HSDir for a hidden > > service (so you can learn its address and measure its popularity), > > and then how to become all the HSDirs for a hidden service so you can > > tell users it's not there. That part is novel and neat. The second idea > > explores, very briefly, how guard rotation puts hidden services at risk > > over the course of months. Imo this second issue, which I think is the one > > you're interested in, is much better explored in Tariq's WPES 2012 paper: > > http://freehaven.net/anonbib/#wpes12-cogs > > and you should realize that the risk applies to all Tor users who use > > Tor over time and whose actions are linkable to each other (e.g. logging > > in to the same thing over Tor). > > There was also a secondary point in the paper that we should not > overlook: you can determine the Guard nodes in use for a hidden service > in a very, very short period of time (apparently around hour?). > > If you have any coercive ability over those Guard nodes, you can then > demand that they assist you in identifying the hidden service IP. > > Additionally, as far as I can see, if you can control the HSdir > points using the attack from the first part of the paper, you could also > perform this attack against a *user* as well (which is the threat model > strongbox really tries to address). A captured HSDir could > repeatedly fail descriptor fetches, forcing the user to reconnect on > new circuits until their Guard node is discovered. > > > Hidden services do seem inherently at a disadvantage, because the > > attacker can dictate how often they talk to the network. Whether that > > disadvantage is significant depends on how pessimistic you are about > > the rest of the problem. > > Yes, specifically: this part of the attack is enabled because the > counterparty is able to manipulate their peer's circuits, and induce > them to retry their connection repeatedly on new circuits (or otherwise > make a lot of new ones). > > Is there a reason why services should use a fresh rend circuit for each > client? > > Moreover, if a circuit succeeds during building, but fails to introduce > or rendezvous, why not simply try again on the same initial portion of > the circuit (but using a different intro point/rend point) rather than a > whole new one? > > It seems to me that in general, both parties should be way more > insistent on re-using circuits that they think should otherwise work, > before trying to make a whole bunch of new ones (especially under > conditions that can be directed/manipulated by the adversary). > > > "Sooner if you help", I think is the phrase the Debian folks use? :) > > If nobody can think of any immediate reasons why we wouldn't want to > make these changes to hidden service circuit use and lifetimes, I will > go ahead and make a new ticket and start thinking about it deeper. https://trac.torproject.org/projects/tor/ticket/9001 After looking into how hard it would be to change the DESTROY and rend circuit use behavior (would require a network upgrade and a full protocol redesign), I think I am leaning towards the creation of a "Virtual Circuit" abstraction layer that would enforce the use of the same 3 hops even after the majority of forms of circuit failure. This would slow discovery of the Guard node by removing the ability of the adversary to expose you to all the middle nodes in the network in a short period of time through circuit failure attacks. -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev