Open Bug 1366202 Opened 7 years ago Updated 1 year ago

Randomize HTTP requests to defend against traffic fingerprinting (Tor 5282)

Categories

(Core :: Networking, enhancement, P5)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

People

(Reporter: ethan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor][necko-would-take]) 

The original Tor ticket: https://trac.torproject.org/projects/tor/ticket/5282
The Tor patch: https://torpat.ch/5282

Quote from the patch comment:
"The main control nob for this patch is now the about:config pref
network.http.pipelining.max-optimistic-requests. The value of that pref
represents the minimum number of pipelined requests we will attempt to batch
together.

The total outstanding pipeline size is randomized between that value and
network.http.pipelining.maxrequests on a per-host basis."
Blocks: uplift_tor_fingerprinting
See Also: → http-fingerprint
Whiteboard: [tor][fingerprinting][fp:m2]
An article for reference although some contents were out-of-date.
https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting
Priority: -- → P1
We should not tag this a blocking the fingerprinting meta bug because even though "fingerprinting" shows up this is not related to fingerprinting via browser features we commonly speak about. Additionally, Mike Perry has been working on this quite some time ago and I am not sure how effective that defense is at all currently and whether we could do something better instead to help with traffic fingerprinting resistance. Let me ask him and get the feedback back into this bug.
(In reply to Georg Koppen from comment #2)
> We should not tag this a blocking the fingerprinting meta bug because even
> though "fingerprinting" shows up this is not related to fingerprinting via
> browser features we commonly speak about. Additionally, Mike Perry has been
> working on this quite some time ago and I am not sure how effective that
> defense is at all currently and whether we could do something better instead
> to help with traffic fingerprinting resistance. Let me ask him and get the
> feedback back into this bug.

Thanks, Georg!
No longer blocks: uplift_tor_fingerprinting
Priority: P1 → P3
Whiteboard: [tor][fingerprinting][fp:m2] → [tor][fingerprinting][fp-backlog]
Support for HTTP Pipelining was removed in Firefox 54 by bug 1340655.
Depends on: 1340655
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
(In reply to Chris Peterson [:cpeterson] from comment #4)
> Support for HTTP Pipelining was removed in Firefox 54 by bug 1340655.

I think the Tor patch randomized both pipelining and non-pipelining requests.
Even if HTTP pipelining was removed in Firefox, we still need to deal with non-pipelining requests.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Randomize non-pipelined requests to defend against traffic fingerprinting (Tor 5282) → Randomize HTTP requests to defend against traffic fingerprinting (Tor 5282)
Ethan, can you suggest someone to drive this, update the patch and submit it for review? Thanks!
Flags: needinfo?(ettseng)
Whiteboard: [tor][fingerprinting][fp-backlog] → [tor][fingerprinting][fp-backlog][necko-would-take]
(In reply to Ethan Tseng [:ethan] from comment #5)
> (In reply to Chris Peterson [:cpeterson] from comment #4)
> > Support for HTTP Pipelining was removed in Firefox 54 by bug 1340655.
> 
> I think the Tor patch randomized both pipelining and non-pipelining requests.

What makes you believe the latter? From the original blog post (https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting): "The defense is to enable HTTP pipelining, and to randomize the pipeline size as well as the order of requests". And skimming over the code seems to support that.
(In reply to Georg Koppen from comment #7)
> (In reply to Ethan Tseng [:ethan] from comment #5)
> > I think the Tor patch randomized both pipelining and non-pipelining requests.
> 
> What makes you believe the latter? From the original blog post
> (https://blog.torproject.org/blog/experimental-defense-website-traffic-
> fingerprinting): "The defense is to enable HTTP pipelining, and to randomize
> the pipeline size as well as the order of requests". And skimming over the
> code seems to support that.

I was confused. Thanks for the clarification.
Flags: needinfo?(ettseng)
(In reply to Valentin Gosu [:valentin] from comment #6)
> Ethan, can you suggest someone to drive this, update the patch and submit it
> for review? Thanks!

Hi Valentin, we don't have a solution for this bug yet.
Perhaps it's very difficult to deploy an effective defense to the website traffic fingerprinting issue on the client side.
But we tend to leave this bug in the backlog.  Is that fine with you?
(In reply to Ethan Tseng [:ethan] from comment #9)
> But we tend to leave this bug in the backlog.  Is that fine with you?
Sounds good. Thanks!
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P3 → P5
Why is this necko-would-take?

From the tor POV, this is an important feature to have, so anonymity can be maintained.
Flags: needinfo?(valentin.gosu)
(In reply to brunoais from comment #12)
> Why is this necko-would-take?
> From the tor POV, this is an important feature to have, so anonymity can be maintained.

necko-would-take is used to signal that the necko team is willing to review & accept a patch for this, but we don't have the time to implement this ourselves at the moment.
Flags: needinfo?(valentin.gosu)
OK. thank you.
Blocks: meta_tor
Whiteboard: [tor][fingerprinting][fp-backlog][necko-would-take] → [tor][necko-would-take]
Severity: normal → S3
Status: REOPENED → NEW
You need to log in before you can comment on or make changes to this bug.