Roger Dingledine: > On Mon, May 27, 2013 at 11:39:06AM -0700, Micah Lee wrote: > > Would it be fair to say that using the techniques published in this > > paper an attacker can deanonymize a hidden service? > > Yes, if you're willing to sustain the attack for months. > > 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 introduction 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 Introduction Point could repeatedly fail circuits, forcing the user to reconnect on new ones until their Guard node is discovered. Of course, most users will probably give up trying to use the service long before the hour is up, but if the attack could be optimized in any other way, it could mean trouble.. > 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. -- 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