Experimental website traffic fingerprinting defense

For grins, I decided to make an experimental fingerprinting defense to defend against http://lorre.uni.lu/~andriy/papers/acmccs-wpes11-fingerprinting.pdf.

Basically the defense is to enable HTTP pipelining and to randomize the size and the order of the pipeline queue for each connection. It's easy to do and doesn't cost us any overhead.

I think we should ask the researchers to test it out for us or give us their source code.

changed milestone to %TorBrowserBundle 2.2.x-stable

added MikePerryIterationFires20110911 actualpoints::2 backport-to-mozilla component::firefox patch issues milestone::TorBrowserBundle 2.2.x-stable owner::mikeperry parent::7027 points::2 priority::medium resolution::fixed status::closed type::enhancement labels

The patch will have two parameters, which I am going to just hardcode in for now, but if anyone shows any interest in testing various values I can pretty easily convert them to about:config prefs.

maxrequests - the maximum number of requests to put into a pipeline minrequests - the minimum number of requests to put into a pipeline

These are set right now to 12 and 4, respectively. There is a uniform distribution among the queue sizes between these two values. The request ordering should be randomized amongst all currently pending requests on a connection.

There are routinely enough requests to create 12-request pipelines. It is possible we could raise this value much higher (though there is a static compiled-in limit).

I think this one stands a decent chance of working with the right parameters, if the torified HTTP pipeline ends up behaving like I expect on the wire. But I could be wrong?

Minor correction: if there are less than minrequests available, we will just put those in a pipeline and send them, rather than wait.

Trac:
Milestone: N/A to TorBrowserBundle 2.2.x-stable

Patch is in my TBB firefox-6.0.1 branch awaiting merge. It should show up as 0006-Randomize-HTTP-pipeline-order-and-depth.patch in the src/current-patches directory of torbrowser.git.

Trac:
Actualpoints: N/A to 2
Status: new to closed
Resolution: N/A to fixed
Points: N/A to 2

FYI, I actually implemented this as 4..4+maxrequests, with network.http.pipelining.maxrequests serving as maxrequests.

Let me know if anyone desires a lower bound parameter.

Trac:
Parent: N/A to #2871 (closed)

Trac:
Summary: Experimental Website fingerprinting defense to Experimental website traffic fingerprinting defense

Here is a direct link to the Firefox patch: https://gitweb.torproject.org/torbrowser.git/blob/maint-2.2:/src/current-patches/0006-Randomize-HTTP-pipeline-order-and-depth.patch

Blog post describing the feature and why we decided on it in more detail: https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting

Trac:
Keywords: N/A deleted, backport-to-mozilla added

Replying to StrangeCharm:

It seems mighty early in the research process to consider a backport of this idea to Firefox. Nobody even knows yet how good an idea it is.

I guess it depends on Firefox's stance on ideas like that. :)

Replying to arma:

I'm just using backport-to-mozilla to keep track of features that I think look interesting. There's a whole other process to actually add them to the Mozilla roadmap, land them, and so on. Don't get your hopes up too soon.

Trac:
Parent: #2871 (closed) to #7027 (moved)

closed

changed time estimate to 16h

added 16h of time spent

mentioned in issue #5282 (closed)