Traffic pattern recognition can apparently be used to achieve a high degree of confidence of the origin of certain traffic, based on statistical analysis of exit node traffic.

Is it possible to mitigate this in any way?

I guess it may be possible to try and create behavioral noise on exit nodes but this sounds like a very problematic approach. Are there any other approaches?

  • You didn't state clearly if the adversary can only watch the exit node or other points of the network too. Also i assume you're talking about SSL encrypted traffic.
    – alaf
    Commented Sep 26, 2013 at 0:18
  • 1
    It is 'Tor', not 'TOR' :)
    – user66
    Commented Sep 26, 2013 at 8:24
  • 1
    I wasn't actually thinking about SSL traffic to be honest. I was considering a highly resourced analyst with the capacity to monitor a lot of exit nodes.
    – barrymac
    Commented Sep 26, 2013 at 10:14
  • 1
    Hm. I suggest you retitle your question to something like "Are there any good techniques to prevent somebody who's looking at my traffic patterns from realizing I'm using Tor?" (since that's what Philipp answered), and then try your original question anew -- but first look through freehaven.net/anonbib and learn about the phrase "correlation attack". Commented Sep 26, 2013 at 10:25

2 Answers 2


First, you have to distinguish between Deep Packet Inspection (DPI) and actual traffic analysis. DPI only looks at packet payload whereas traffic analysis looks at everything other than payload, e.g., packet lengths, bursts and timing.

It is well known that DPI can be used to detect Tor flows. Several countries such as China, Iran and Syria are doing that to detect and block Tor. When looking closely, Tor's TLS handshake looks slightly different from, say, a Firefox talking to an Apache web server. To make Tor resistant against DPI, pluggable transports were introduced a while ago. They are able to make Tor look like Skype, some sort of HTTP, or random bytes.

Traffic analysis, on the other hand, is a slightly different beast. Among other things, a Tor connection can be identified by only counting the amount of 586-byte packets (that's Tor's 512-byte cells plus header overhead). Tor connections exhibit a rather high amount of these packets. There are also pluggable transport protocols to obfuscate these characteristics but strong defence against traffic analysis is believed to be very expensive. So the current approach is to make traffic analysis less effective but not impossible. After all, traffic analysis can only give you a probabilistic answer (I'm 40% sure, this is Tor) rather than a deterministic one (I'm sure this is Tor because no other application uses such a handshake) as DPI can.

  • Not all pluggable transports make traffic look like Skype's. Some just make traffic look like random gibberish.
    – alaf
    Commented Sep 26, 2013 at 0:16

Using multiple gateway VMs (pfSense for openvpn and OpenWRT for Tor) and accounts with multiple VPN privacy services, it's possible to route one VPN tunnel through another, and route Tor through an arbitrarily-complex nested chain of VPN tunnels. Using such setups, it's easy to add cover traffic to obscure Tor traffic. For example, you might only use Tor while participating in BitTorrent swarms through multiple VPN routes.

Although Tor traffic exiting the terminal VPN exit node would not be obscured, associating that traffic with you would require compromising multiple VPN service providers. That risk can be reduced by selecting providers in poorly-cooperating spheres of influence, and by paying anonymously for service with cash by mail. One can also pay with with Bitcoins that have been mixed multiply through multiple mixing services, using Multibit wallets in multiple Tor VMs (such as Whonix).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .