[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Practical web-site-specific traffic analyses

On Fri, Jul 30, 2010 at 12:32:43PM -0700, Seth David Schoen wrote:
> The simplest threat scenario for Tor users would be when an
> attacker in a position to observe a particular user's traffic,
> but not any exit node traffic, hypothesizes that the user is
> likely to visit a particular site and builds up a profile of
> what web browsing traffic to that site will look like.  The
> attacker could then try to confirm the hypothesis that the
> user is using that site and also try to infer some details of
> what the user is doing.  This is quite different from traffic
> confirmation because the attacker only has to be present at
> one end.

Yes, this has been a known risk with all currently deployed
low-latency anonymity systems. One recent paper which looked at the
problem was discussed here:


and the full paper is here:


What they found is that single-hop proxies were easily broken (>95%
accuracy), but multi-hop systems were more of a challenge. The attack
against JonDo was about 20% accurate and against Tor it was only 3%

This doesn't mean that multi-hop systems are safe though, because the
attack assumed that the anonymity system didn't add any extra traffic.
In fact, Tor and JonDo do add quite a bit of extra traffic, and it was
probably this which confused the attack. Much of this traffic can be
identified and if it were removed before the traffic analysis was
performed, the accuracy would likely go up by quite a bit.

To fix this attack, systems can add dummy traffic (padding), delay
packets, and/or drop packets. Tor adds a bit of padding, but unlikely
enough to make a difference. Tor doesn't (intentionally) drop or delay

More research is needed before we will know how to best to use and
combine these traffic analysis resistance techniques. I co-authored a
paper on some aspects of this problem, but while the combination of
delaying and padding is promising, more needs to be done before this
can be deployed in a production system:



To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/