We need to prevent 3rd party domains from being able to correlate activity using HTTP Keep-Alive connections. We limited this linkability in legacy/trac#4603 (closed), but we should solve it entirely, if we can.
Designs
Child items
0
Show closed items
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Linked items
0
Link issues together to show that they're related.
Learn more.
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 legacy/trac#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 legacy/trac#4603 (closed), but we should solve it entirely, if we can. Priority: normal to major
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.
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.
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 (legacy/trac#14952 (moved)) as the keep-alive mechanisms in both protocols should not be much different.
Thanks to Patrick McManus for a helpful discussion.