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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev