Opened 6 years ago

Closed 6 years ago

#8470 closed defect (fixed)

Request randomization a lot less random in FF17

Reported by: mikeperry Owned by: mikeperry
Priority: Very High Milestone:
Component: Firefox Patch Issues Version:
Severity: Keywords: tbb-rebase-regression, MikePerry201304
Cc: t55wang, mcs Actual Points: 26
Parent ID: Points:
Reviewer: Sponsor:

Description

I decided to take a closer look at the actual request ordering in our Firefox builds, and it appears a lot less random than when I first tested the pipeline randomization patch.

This could be due to a regression before FF10, since the last time I tested it was ~FF7/8, but most likely it was introduced between 10 and 17, when I rewrote the patch completely.

Child Tickets

Attachments (1)

IncreaseRandomization.diff (3.5 KB) - added by mikeperry 6 years ago.
Some potential ideas.

Download all attachments as: .zip

Change History (9)

comment:2 Changed 6 years ago by mikeperry

Priority: majorcritical

I'm going to call this critical, since it is important that researchers study a functional defense.

comment:3 Changed 6 years ago by mcs

Cc: mcs added

comment:4 Changed 6 years ago by mikeperry

mcs: FYI I did some investigation into this the other day. Attaching a patch with some ideas. Haven't tested it yet.

Changed 6 years ago by mikeperry

Attachment: IncreaseRandomization.diff added

Some potential ideas.

comment:5 Changed 6 years ago by mikeperry

Keywords: MikePerry201304 added

comment:6 Changed 6 years ago by mikeperry

Ok, I've been testing that patch with a debug build + logs for a bit. I've discovered that quite a few of the pipeline connections are hitting the hardcoded timeout of 1.5 seconds and getting rescheduled. This might not be too bad, because it should just create more opportunities for randomization, *except* that the code also marks connections that timeout as unsuitable for future pipelining. Once the connection limit is hit, pipelining then stops entirely.

So in effect, for large websites, pipelinining is almost completely disabled for Tor by this timeout. It looks like this specific pref+variable were a new addition to the FF17 code during the pipelining rewrite, but there may have been an analog to this timer in FF10 and before...

comment:7 Changed 6 years ago by mikeperry

It turns out that pipeline behavior is significantly different in debug vs non-debug builds. In debug builds (especially if debug logs are enabled), the browser is often too slow to be able to keep the pipeline full of requests, and requests aren't packed together in Tor cells.

This might be important, because it may also be the case that a browser that is driven around by selenium in a VM might be similarly too slow for pipelining's request combining to happen.

I'll be updating the pipeline patch to have an option to log the pipeline state as requests are sent separately from debug logs to help diagnose this.

comment:8 Changed 6 years ago by mikeperry

Actual Points: 26
Resolution: fixed
Status: newclosed

I put quite a bit of work into this, and I'm fairly satisfied that the new patch in origin/maint-2.4 is at least a good improvement. The basic idea is to restrict new connection creation until we have enough requests to batch together (governed by a pref) in a new pipeline.

Read the patch description for more details:
https://gitweb.torproject.org/torbrowser.git/blob/maint-2.4:/src/current-patches/firefox/0017-Randomize-HTTP-request-order-and-pipeline-depth.patch

The patch still does not deal with SPDY directly.

Note: See TracTickets for help on using tickets.