Opened 7 years ago

Closed 7 years ago

#4099 closed defect (fixed)

Disable TLS Session resumption and Session IDs

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone: TorBrowserBundle 2.2.x-stable
Component: Firefox Patch Issues Version:
Severity: Keywords: MikePerryIteration20111211
Cc: gk, ioerror Actual Points: 2
Parent ID: Points: 2
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (21)

comment:1 Changed 7 years ago by mikeperry

Cc: gk added

gk - You guys disable HTTP Keep-alive to prevent 3rd party correlation, right? Do you do anything about TLS Session IDs across different tabs/domains?

comment:2 in reply to:  description ; Changed 7 years ago by 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?

comment:3 in reply to:  2 ; Changed 7 years ago by mikeperry

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. 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?

comment:4 in reply to:  1 Changed 7 years ago by gk

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.

comment:5 in reply to:  3 Changed 7 years ago by gk

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.

comment:6 Changed 7 years ago by ioerror

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

comment:7 Changed 7 years ago by ioerror

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

comment:8 Changed 7 years ago by mikeperry

Keywords: MikePerryIterationReport2011106 added
Points: 1

Not quite what we need, but I actually wasn't aware this pref existed. I'll verify it does what we think in the source, and get this in the next release.

comment:9 Changed 7 years ago by mikeperry

Keywords: MikePerryIteration20111106 added; MikePerryIterationReport2011106 removed

comment:10 Changed 7 years ago by gk

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:

1) Load https://anonym-surfen.de (in it an image from https://ip-check.org is loaded)
2) Load https://twitter.com
3) Load https://anonym-surfen.de
4) 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.

comment:11 Changed 7 years ago by mikeperry

Keywords: MikePerryIteration20111120 added; MikePerryIteration20111106 removed

comment:12 in reply to:  10 Changed 7 years ago by gk

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.

comment:13 Changed 7 years ago by gk

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.

comment:14 Changed 7 years ago by 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?

So technically, I guess that means we should apply the pref, close this ticket, and open a new one to disable SSL Session IDs?

comment:15 in reply to:  14 Changed 7 years ago by gk

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).

comment:16 Changed 7 years ago by mikeperry

Keywords: MikePerryIteration20111211 added; MikePerryIteration20111120 removed

comment:17 Changed 7 years ago by mikeperry

Points: 12
Summary: Disable TLS session resumption and HTTP keep-aliveDisable TLS Session resumption and Session IDs

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).

comment:18 Changed 7 years ago by mikeperry

Cc: ioerror added

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.

comment:19 Changed 7 years ago by mikeperry

It works!

comment:20 Changed 7 years ago by ioerror

It looks like we're doing well with this bug - what more do you need from me?

comment:21 in reply to:  20 Changed 7 years ago by mikeperry

Actual Points: 2
Resolution: fixed
Status: newclosed

Replying to ioerror:

It looks like we're doing well with this bug - what more do you need from me?

Nothing. I just wanted to make sure you were aware that the pref was not enough, and that a Firefox patch was required to address this fully.

Note: See TracTickets for help on using tickets.