Comment by nanoscopic | Hacker News Reader

Comment by nanoscopic | Hacker News Reader

I already posted publicly online how to find the identity of a Tor user.

To reiterate:

1. Get the Tor user in question to visit a website controlled by you ( or at least a site where you can cause JS to run; such as an advertisement )

2. Know which ISP the user is on, and be allowed to install a high speed device watching all traffic for a sequence of specific sized packets.

3. Use the JS to send a specifically crafted sequence of sized packets with specific time periods in between them. After sending this preamble, send sized packets to send the 'pseudo identity' of the user ( whatever pseudonym you wish to attach back to their real IP )

4. Use your monitored ISP device to detect the preamble, then log IP and the data.

Note this method could be done en-masse and would only require high speed FPGA devices at each ISP "trunk". Inject JS code correlating users back for any system which you wish to identify the users.

Done. Whichever Russian demonstrates this and wins the $100k; throw me a bone please. :)

>( or at least a site where you can cause JS to run; such as an advertisement )

So you cannot find the identity of a tor user.

* Either the TOR user is a 'newbie' (no offense), and he will use the tor package wich come with a version of firefox where JS is disabled by default

* Either he is a seasoned user and knows that disabling JS while using TOR is mandatory.

I don't know the exact parameters of the competition, but I doubt pretty strongly if the solution is allowed to manipulate the targeted user's behavior, and, oh, by the way, install a high speed listening device on the trunk of every ISP in the world.

If you have to know already which ISP the suspected user is using, you're not really finding the user, you're just confirming their identity.

And as others have pointed out, running with JS enabled is a vulnerability. If the user is that careless, it's probably easier to get them to load a particular file over plain HTTP and just listening to requests for that file.

I assume a Tor user with js turned off would be immune to this?

I wonder if something similar could be done with detecting specifically sized images?

I think this will be a bit harder, as you don't really have control in what order the images are being loaded. They could be loaded in parallel for example. If you try to circumvent it by adding delay's on the server side you quickly block the browser as you will reach the maximum amount of parallel connections.

You're all making this much too complicated. Who needs the client to make multiple requests when you control the server? Client does "GET /" and the server starts sending a large index.html using irregular sized packets at specific intervals.

But suppose we broke it, now we have to fix it, right? Start padding everything to power-of-two size boundaries with a minimum of 16. Or if that would make Tor traffic too identifiable, then instead add random()%packetsize padding to each packet. Either would reduce the number of detectable packet sizes below a 1500 byte MTU to 8 at the cost of less than doubling the bandwidth consumption.

I don't think so. What you could do is have the webserver set up chunked encoding on a resource (say an image) and vary the size of the chunks for each user.

I thought Tor padded all packets to obscure payload size. Is this not true, or does this method work in some other way I'm not grokking?

Even simpler: create a website which responds in a recognizable way, serially rather than concurrently. If person A received recognizable packet P at time T, and the site was serially serving that connection at time T to recognizable-but-pseudonymous person X, then A==X.

> 2. Know which ISP the user is on

How easy would it be to do this (even with JS on)?

Reply on news.ycombinator.com