Re: [tor-talk] on the topic of tor's weaknesses

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Wed, Feb 29, 2012 at 05:17:34AM -0500, grarpamp wrote:
> > The main problem, besides the overhead, is that padding doesn't work
> > if an adversary can do something as trivial as very briefly delaying
> > It is too easy for an adversary to put a traffic signature on a
> > circuit in one place, and look for it elsewhere. If he owns, e.g., the
> > first node and any of the last node, the link to the destination, or
> > the destination it won't matter what kind of padding is done. There's
> > lots of published work showing this in various ways. Some already
> > alluded to in this thread. If nothing else the adversary can just kill
> > the connection at the first node and see which connection exiting the
> > network dies.
> 
> Doesn't this mean bad news for users of hidden services,

Maybe. The important thing is to understand what security is provided
and what is not. Then you can make an informed decision about whether
or not it's bad news.

> and to a
> lesser extent clearnet services (since they're not as 'illegal' and thus
> maybe lesser hot targets for snagging users). IE:
> 
> Sting runs a HS and an entry. Thus Sting has full packets, timing,
> cleartext and logs of anyone that builds: clientA <> entry <---> HS
> 
> There may even be these additional structures to the left of clientA's
> entry, for which the role of entry may switch to relay or exit, but for
> which entry may be still able to discriminate among on its left...
> clientB
> clientC <> relay
> clientD [...] <> relay <> relay [...]
> 
> It may take a while for a clientA to use said entry but when they do it seems
> it would be quite easy to time/count correlate or munge the HS traffic of
> clientA. And only require two nodes (hs, entry) and no GPA taps to do so.
> 
> Can such an entry know when it's being used as an entry by
> whatever appears to it's left? I think that is what I describe
> relies on.

The short but incomplete answer is yes. Generally, what you are
describing we experimentally verified on the live Tor network back in
2005.  See "Locating Hidden Servers" by Lasse Overlier and myself.
Available at 
http://freehaven.net/anonbib/ 
or
http://www.onion-router.net/Publications.html

These sorts of attacks are what motivated us to introduce guard nodes,
also described in that paper.  We all knew, and had seen analyzed in
earlier work by Wright et al., that onion routing circuits were
subject to predecessor attacks, and that what Wright et al. had called
helper nodes would, well help.  What Lasse and I showed was that the
public Tor network as of 2005 was subject to such attacks working very
quickly (minutes) using very limited resources. You could generally
find a hidden server within minutes using just a single hostile Tor
relay (no cooperation from evil web server required). We wanted to
show what you could do with a single relay, which limited us to hidden
server circuits. If you owned at least two relays, you could attack
arbitrary Tor circuits. This was confirmed in simulation on PlanetLab
shortly after by Bauer et al.  ("Low-Resource Routing Attacks Against
Tor", also available at anonbib).

Entry guards don't change the asymptotic threat of such attacks, they
just move it around. Since you could be screwed so quickly and easily
by building random circuits, Tor was changed so that you pick just a
few relays as your entry guards. If one of them is evil, it will see
the entry side of (a large fraction of) your circuits and will be able
to associate you with your destination whenever you go to a hostile
destination or use a hostile exit. What Lasse and I showed was that
you weren't really much worse off from this than when choosing
circuits with random entry relays. And if none of your guards is evil,
an adversary can never de-anonymize you in this way. (Never say
"never". ;>) Cf. the experiments and discussion of layered guards in
"Locating Hidden Servers", and our subsequent research on building
trust into path selection.)

aloha,
Paul
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk