Disable TLS Session resumption and Session IDs
We need to disable TLS session resumption and HTTP keep-alive to prevent third parties from possibly using them to track users between different domains.
Ideally, we should simply prevent 3rd party origins from using these two features, but I suspect that differentiating 3rd party loads at the HTTP and TLS layers will prove difficult.
Activity
changed milestone to %TorBrowserBundle 2.2.x-stable
Replying to mikeperry:
We need to disable TLS session resumption and HTTP keep-alive
Isn't disabling http keep-alive really harmful for performance?
Replying to arma:
Replying to mikeperry:
We need to disable TLS session resumption and HTTP keep-alive
Isn't disabling http keep-alive really harmful for performance?
Yes. Also, some more research reveals that disabling keep-alive will also prevent pipelining, which would eliminate our experimental website fingerprinting defense (https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting).
I guess keep-alive will have to wait for #4100 (moved). TLS session IDs are the worse of the two anyway, as they persist for longer.
We can reduce the duration of HTTP keep-alive even more, though. Right now it is 115 seconds... Should we lower it?
Replying to mikeperry:
gk - You guys disable HTTP Keep-alive to prevent 3rd party correlation, right? Yes (proxy keep-alive), that is vital to JonDonym and its static mix cascades currently. Do you do anything about TLS Session IDs across different tabs/domains? I am working on it at the moment although I fear binding it to the tab could be really tricky. To take the domain is probably easier here.
-
Yes. Also, some more research reveals that disabling keep-alive will also prevent pipelining, which would eliminate our experimental website fingerprinting defense (https://blog.torproject.org/blog/experimental-defense-website-traffic-fingerprinting). Indeed, that is true as pipelining is bound to keep-alive at least in Mozilla. Nevertheless I could imagine some kind of "pipelining" even if keep-alive is off. There seems no strong connection between keep-alive and randomizing request order to me.
security.enable_tls_session_tickets needs to be set to false according to this: http://www.gossamer-threads.com/lists/apache/dev/382736?do=post_view_threaded
Here's my patch for reducing SSL session linkability:
diff --git a/src/chrome/content/torbutton.js b/src/chrome/content/torbutton.js index 966e574..18fcee0 100644 --- a/src/chrome/content/torbutton.js +++ b/src/chrome/content/torbutton.js @@ -1949,6 +1949,10 @@ function torbutton_update_status(mode, force_update) { !m_tb_prefs.getBoolPref("security.enable_ssl2")); } + // Disable ssl session identifiers + // https://trac.torproject.org/projects/tor/ticket/4099 + m_tb_prefs.setBoolPref("security.enable_tls_session_tickets", false); + // This clears the OCSP cache. // // nsNSSComponent::Observe() watches security.OCSP.enabled, which calls-
I am not sure what the pref is actually doing yet but according to my test setup with ssldump it won't help us here. I tested the following with ssldump listening:
- Load https://anonym-surfen.de (in it an image from https://ip-check.org is loaded)
- Load https://twitter.com
- Load https://anonym-surfen.de
- Load the image URL as first party (I tweaked a parameter of this URL slightly to avoid caching issues)
At least for the image I could verify that the same session ID is used throughout 1)-4) and "security.enable_tls_session_tickets" was set to "false".
I hope I did something wrong here but I already double-checked my results and it does not seem to be the case.
-
At least for the image I could verify that the same session ID is used throughout 1)-4) and "security.enable_tls_session_tickets" was set to "false".
I hope I did something wrong here but I already double-checked my results and it does not seem to be the case.
Replying to myself: After some more digging it turns out that Session ID tracking and tracking via TLS resumption are different beasts (see: https://tools.ietf.org/html/rfc5077 especially sections 3.4 and 5.8). That would explain the still available session ID mentioned above even if the pref in question is disabled.
-
And I can confirm that the pref is oding what it should: With Session Resumption enabled I get (in the ClientHello):
extension type server_name, length [14] = {...} extension type elliptic_curves, length [8] = {...} extension type ec_point_formats, length [2] = {...} extension type session_ticket, length [0]Without I get (again in the ClientHello):
extension type elliptic_curves, length [8] = {...} extension type ec_point_formats, length [2] = {...}Not sure why the server_name extension is missing in the latter case, though. I connected to the same server.
-
Replying to mikeperry:
gk: So you're saying that while the pref does in fact disable TLS session resumption, it does not disable SSL Session IDs, correct?
Yes.
So technically, I guess that means we should apply the pref, close this ticket, and open a new one to disable SSL Session IDs?
Yes. And maybe you could update the TorBrowser spec accordingly (section 3.5.6).
-
I suspect SSL Session ID use is going to be governed by a flag passed in to the NSS libs somewhere. Might as well roll it into this bug. As for HTTP Keep-Alive.. I think we need to ponder that one a bit more. Breaking it off into the new ticket (#4603 (closed)).
Trac:
Points: 1 to 2
Summary: Disable TLS session resumption and HTTP keep-alive to Disable TLS Session resumption and Session IDs -
At first glance, it looked like this was doable by calling SSL_ConfigServerSessionIDCache() during nsNSSComponent::InitializeNSS(). However, the system appears to be written to use a default session ID cache size if you set it to 0.
There does appear to be an SSL_NO_CACHE option that can be set with SSL_OptionSet(), as well as an ssl_defaults that we can bang on to disable session ID caching for each individual ssl socket.
I am going to try that and see what happens.
Trac:
Cc: gk to gk, ioerror