Opened 8 years ago

Closed 4 years ago

#4100 closed enhancement (fixed)

Isolate SPDY and HTTP Keep-Alive to top-level domain

Reported by: mikeperry Owned by: gk
Priority: High Milestone: TorBrowserBundle 2.3.x-stable
Component: Applications/Tor Browser Version:
Severity: Keywords: tbb-linkability, tbb-firefox-patch, tbb-4.5-alpha, tbb-usability-website, TorBrowserTeam201504, MikePerry201504R
Cc: mcs, arthuredelstein, gk Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

We need to prevent 3rd party domains from being able to correlate activity using HTTP Keep-Alive connections. We limited this linkability in #4603, but we should solve it entirely, if we can.

Child Tickets

Change History (15)

comment:1 Changed 7 years ago by mikeperry

Keywords: tbb-linkability added

comment:2 Changed 7 years ago by mikeperry

Description: modified (diff)
Priority: normalmajor
Summary: Isolate TLS Session IDs and HTTP Keep-Alive to top-level domainIsolate SPDY and HTTP Keep-Alive to top-level domain

The NSS code is so decoupled from the rest of Firefox that I think expecting to re-enable TLS Session IDs after binding them to top-level domain is out of the question. Let's just make this ticket focus on binding HTTP Keepalive and SPDY to top-level domains.

comment:3 Changed 5 years ago by erinn

Keywords: tbb-firefox-patch added

comment:4 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Owner: changed from mikeperry to tbb-team

comment:5 Changed 4 years ago by mcs

Cc: mcs added

comment:6 Changed 4 years ago by arthuredelstein

Cc: arthuredelstein added

comment:7 Changed 4 years ago by gk

Cc: gk added

Don't we get the isolation we need for free with our current implementation of "Use different circuits for different URL bar domains"?

I made a quick test with loading google.com and https://people.torproject.org/~gk/misc/keep-alive.html (which loads a resource requested as well if one loads google.com) making sure I did that within our current keep-alive limit and all requests are properly isolated meaning they use different circuits. How should the keep-alive you get while loading google.com interfere with the one you get if loading keep-alive.html provided they use different exit nodes?

Recalling the discussion on IRC with s7r I think that would even mitigate the problem of onion sites loading foo.com clearnet resources while having foo.com open in a different tab.

What am I missing?

comment:8 Changed 4 years ago by mikeperry

Keywords: tbb-4.5-alpha TorBrowserTeam201503 tbb-usability-website added

We should investigate this closer and determine if it is in fact properly isolated with the new nsIChannelProxyFilter code. If so, we can raise our Keep-alive timeout and it will greatly help with usability of things like etherpads, webmail, and google docs.

comment:9 Changed 4 years ago by mikeperry

Incidentally, the keep-alive pref is network.http.keep-alive.timeout. Raising it to a large value (and verifying the HTTP headers allow it, as well as monitoring the control port and possibly watching localhost for 9150 SOCKS activity with wireshark) might make this easier to reproduce.

comment:10 Changed 4 years ago by gk

I started to use another example: blog.torproject.org and https://people.torproject.org/~gk/misc/keep-alive.html which basically loads a resource from blog.torproject.org. I bumped the timeout to 115 which my non-TorBrowser browser is using as well and monitored the control port + the headers. It still looks fine.

I'll have Wireshark sniffing traffic the next time and will start looking at the actual Mozilla code.

comment:11 Changed 4 years ago by mikeperry

Keywords: TorBrowserTeam201504 added; TorBrowserTeam201503 removed

comment:12 Changed 4 years ago by gk

The wireshark test showed nothing which is good. Still digging through the code.

comment:13 Changed 4 years ago by mikeperry

Keywords: MikePerry201504R added
Owner: changed from tbb-team to gk
Status: newassigned

I can also try to have a look at the code at some point.

comment:14 Changed 4 years ago by gk

Status: assignedneeds_review

The SOCKS username (which is the URL bar domain) and the password go into the hash key that is crucial when deciding if a connection should be reused or not (see nsHttpConnectionInfo::SetOriginServer()). If the network is hit then this connection information is used for setting up the corresponding transaction. When the transaction is processed (in nsHttpConnectionMgr::ProcessNewTransaction()) GetOrCreateConnectionEntry() is checking whether there is already a connection entry pointed to by the hash key available. This is not the case if the resource to be loaded (as in my examples above) is bound to a different URL bar domain, i.e. the request is using a different SOCKS username/password. A new connection entry is created but there are no idle connections yet. Thus, the check in TryToDispatch() finding an idle connection with a proper connection entry to which to attaching the transaction to fails. This means keep-alive is isolated to the URL bar domain. (there is no problem either with speculative connections found while looking in the half open list btw as they are hashkey dependent as well).

bug_4100 in my tor-browser repo has two commits fixing this bug wrt to the keep-alive isolation. As we have SPDY disabled investigating this for 4.5 is not urgent and I think we should do that together with auditing HTTP/2 (#14952) as the keep-alive mechanisms in both protocols should not be much different.

Thanks to Patrick McManus for a helpful discussion.

Last edited 4 years ago by gk (previous) (diff)

comment:15 Changed 4 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Ok, this looks good. Glad you added the comment in the source, and thanks for the detailed analysis!

Note: See TracTickets for help on using tickets.