[tor-dev] "Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization"

[Mike Perry]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130528/e23eeec7/attachment.pgp>