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

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

changed milestone to %TorBrowserBundle 2.3.x-stable

added MikePerry201504R TorBrowserTeam201504 component::applications/tor browser milestone::TorBrowserBundle 2.3.x-stable owner::gk priority::high resolution::fixed status::closed tbb-4.5-alpha tbb-firefox-patch tbb-linkability tbb-usability-website type::enhancement labels

Trac:
Keywords: N/A deleted, tbb-linkability added

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.

Trac:
Summary: Isolate TLS Session IDs and HTTP Keep-Alive to top-level domain to Isolate SPDY and HTTP Keep-Alive to top-level domain
Description: We need to prevent 3rd party domains from being able to correlate activity using either TLS Session IDs or HTTP Keep-Alive.

In #4099 (closed), we plan to simply disable TLS session resumption and HTTP keep-alive. Long term, we should try to find a way to preserve these features by preventing them from applying to third parties from different top-level domains.

to

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

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser
Owner: mikeperry to tbb-team

Trac:
Cc: N/A to mcs

Trac:
Cc: mcs to mcs, arthuredelstein

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?

Trac:
Cc: mcs, arthuredelstein to mcs, arthuredelstein, gk

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.

Trac:
Keywords: N/A deleted, tbb-4.5-alpha, tbb-usability-website, TorBrowserTeam201503 added

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.

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.

Trac:
Keywords: TorBrowserTeam201503 deleted, TorBrowserTeam201504 added

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

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

Trac:
Owner: tbb-team to gk
Status: new to assigned
Keywords: N/A deleted, MikePerry201504R added

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 (moved)) as the keep-alive mechanisms in both protocols should not be much different.

Thanks to Patrick McManus for a helpful discussion.

Trac:
Status: assigned to needs_review

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

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

mentioned in issue #5721 (moved)

mentioned in issue #14952 (moved)