Length and Time Attacks

last year

So let's consider this attack model:
The enemy can surveil all traffic at an internet-provider $ISP, therefore all traffic that goes from a $ISP-Customer to the $ISP (or any other customer) and back.
Let's also assume the enemy can surveil all in- and outgoing traffic from/to a specific server $SERVER on the internet.
Let's also assume all traffic is strongly encrypted.

What is at steak? Anonymity: Who uses what service on the internet. Let's assume we ($ISP-Customer) want to use an internet service ($SERVER) but we dont want anyone to know we use it.

Let's talk about those scenarios:

(1) So we are a customer of $ISP and directly connect to $SERVER.
Obviously we are busted. The enemy can see us directly contacting the $SERVER at $ISP-Level, without even having the need to also monitor incoming connections on $SERVER. $ISP-surveillance is fully sufficient at this point.

(2) We are a customer of $ISP but we use a $VPN to connect to $SERVER. This one is not so obvious. The enemy can only see our connection to $VPN and a connection from $VPN to $SERVER.
But something is very telling. The time-frame of the connections made and the length of the packets.
If we use this service long enough about a time period of $X, the correlations are significant. The packets from ($ISP-Customer)<->$ISP<->$VPN and $VPN<->$SERVER occur so much at almost the same time with (alomost?) the same length that any other user can be reasonably ruled out at this point. (correct?)

(3) I wonder. If $ISP-Customer is using Tor to connect to $SERVER is there any change in anonymity in THIS specific attack-model? Because we see AGAIN these connections: ($ISP-Customer)<->$ISP<->$GUARD and at the other end we see $EXIT<->$SERVER with the packets having the (same?) time and length properties for the connection.

Can someone shed some light on this? Thanks!

last year

This is a a well known problem, probably Tor's biggest weakness. It's generally considered difficult to pull off in practice, but it's a risk for sure. There's not much of a way to avoid this unless you switch to a high-latency system (i.e. one that adds deliberate delays, rather than trying to send data as quickly as possible).


You are not logged in. Login or register to reply on this thread.