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

[Mike Perry]

Tom Ritter:

> RPW's, et al's paper was made public today, and demonstrates several
> practical attacks on Hidden Services.
> http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf

Sweet. I was waiting for a public version of this to appear. It was
shared with a few Tor people, but as I don't work on hidden
service-related things, I had not seen it yet.

> I was wondering if there were any private trac tickets, discussions,
> or development plans about this that might be also be made public.

There have been a few discussions on this list about making hidden
service descriptors harder to harvest. Sysrqb pointed out that a lot of
the ideas are captured here:
https://trac.torproject.org/projects/tor/ticket/8106


As for the deanonymization attack, I think it is pretty novel in that it
uses a custom traffic signature to make the attack from
http://freehaven.net/anonbib/cache/hs-attack06.pdf more reliable, but
otherwise that is why we introduced guard nodes.

One immediate thought: what about changing hidden services to maintain a
small pool of service-side rend circuits were reused for as long as
possible (perhaps until they simply failed)?  This would give a similar
effect to multiple layers of guard nodes, but without adding all of that
complexity or extra hops.

We would have to create some logic that prevented DESTROY cells from
being allowed to travel across all 6 hops in that case, though, but
there are actually multiple reasons to make that change.

In general, a client shouldn't be allowed to manipulate a service's
circuits' lifetimes as a general matter, nor should a service be able to
manipulate a client's circuits' lifetimes.

In fact, this ability for remote manipulation of the other party's
circuits caused me to decide that the Path Bias detection code should
not perform accounting on these circuits, because a malicious
counterparty could use that ability to cause you to erroneously lose
faith in your Guard nodes.

Unfortunately this also means that if a path bias/route capture
adversary can differentiate these circuit types, they could fail the
ones we can't do accounting on at will.

So there's now more than one reason to change that DESTROY behavior at
the very least, I think.


-- 
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/20130523/de67d859/attachment.pgp>