Opened 8 years ago

Closed 8 years ago

Last modified 6 years ago

#3914 closed enhancement (fixed)

Experimental website traffic fingerprinting defense

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone: TorBrowserBundle 2.2.x-stable
Component: Firefox Patch Issues Version:
Severity: Keywords: MikePerryIterationFires20110911, backport-to-mozilla
Cc: arma, gk Actual Points: 2
Parent ID: #7027 Points: 2
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 8 years ago by mikeperry

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?

comment:2 Changed 8 years ago by mikeperry

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

comment:3 Changed 8 years ago by mikeperry

Milestone: TorBrowserBundle 2.2.x-stable

comment:4 Changed 8 years ago by mikeperry

Actual Points: 2
Points: 2
Resolution: fixed
Status: newclosed

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.

comment:5 Changed 8 years ago by mikeperry

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.

comment:6 Changed 8 years ago by mikeperry

Parent ID: #2871

comment:7 Changed 8 years ago by mikeperry

Summary: Experimental Website fingerprinting defenseExperimental website traffic fingerprinting defense

comment:9 Changed 8 years ago by mikeperry

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

comment:10 Changed 8 years ago by StrangeCharm

Keywords: backport-to-mozilla added

comment:11 in reply to:  10 ; Changed 8 years ago by arma

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. :)

comment:12 in reply to:  11 Changed 8 years ago by StrangeCharm

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.

comment:13 Changed 6 years ago by mikeperry

Parent ID: #2871#7027
Note: See TracTickets for help on using tickets.