search

arkenfox / user.js

Firefox privacy, security and anti-tracking: a comprehensive user.js template for configuration and hardening
MIT License
9.93k stars 513 forks source link

reminder: 1204: make SSL session IDs inactive #1110

Closed Thorin-Oakenpants closed 3 years ago

Thorin-Oakenpants commented 3 years ago

for discussion

current

/* 1204: disable SSL session tracking [FF36+]
 * SSL Session IDs are unique, last up to 24hrs in Firefox, and can be used for tracking
 * [SETUP-PERF] Relax this if you have FPI enabled (see 4000) *AND* you understand the
 * consequences. FPI isolates these, but it was designed with the Tor protocol in mind,
 * and the Tor Browser has extra protection, including enhanced sanitizing per Identity.
 * [1] https://tools.ietf.org/html/rfc5077
 * [2] https://bugzilla.mozilla.org/967977
 * [3] https://arxiv.org/abs/1810.07304 ***/
user_pref("security.ssl.disable_session_identifiers", true); // [HIDDEN PREF]

proposed

/* 1204: disable SSL session tracking [FF36+]
 * SSL Session IDs are unique and last up to 24hrs in Firefox (or longer with prolongation attacks)
 * [NOTE] In FF85+ they are isolated by default with privacy.partition.network_state. This is
 * overridden when using FPI (4001) which also isolates: as do containers and PB mode
 * [WARNING] There are perf and passive fingerprinting costs, for little to no gain. Preventing
 * tracking via this method does not address IPs, nor handle any sanitizing of current identifiers
 * [1] https://tools.ietf.org/html/rfc5077
 * [2] https://bugzilla.mozilla.org/967977
 * [3] https://arxiv.org/abs/1810.07304 ***/
   // user_pref("security.ssl.disable_session_identifiers", true); // [HIDDEN PREF]

reasons

perf

fingerprinting

tracking

TB

conclusion

This pretty much a broken and useless pref for all setups in Firefox. The real solution would be upstream to limit the lifetime (e.g. to 10 minutes as per the suggestion in the paper), but I doubt that will ever happen.

Class, discuss!

gitthehubs commented 3 years ago

You got some tough decisions to make. :)

I think, but I could be wrong, the main goal of your user.js is to harden your firefox setup and prevent tracking and fingerprinting, performance is secondary or not even a real thing to keep in mind unless the performance impact is really big. And I don't know how long this setting is in the user.js, but I can't say I really noticed some performance drops because of this setting.

So reading your reasons it leaves me with fingerprinting vs tracking. One thing you can ask is how often is this used for fingerprinting and how often is this used for tracking and are there other measures to prevent one of these two? For fingerprinting, how often is this used and how does it affect the entropy? I do understand that if no other browsers use this, disabling session identifier, that the few who do disable the session identifier really stand out, it really make you unique if this is fingerprinted. For tracking, how often is this used for tracking and what is the impact? If I'm correct the tracking can only be done in sites with the same certificate. Considering people use other anti-tracking measures, how big of a deal is this?

Considering that if both are used, I think that fingerprinting is more of an issue than tracking, because no other browser use this setting by default so the people who use it are just a small group and it make you very unique and this fingerprinting technique can follow you over sites if for example trackers use this. The tracking is less of an impact because it is just with the same site or group of sites the use the same certificate. Or do I see this wrong? :)

Thorin-Oakenpants commented 3 years ago

The user.js is a template: so it's about finding a balance which is a little subjective.

The perf issue here is one I haven't really thought about. Having had SSL session ids disabled for four of five years, I can't say I noticed what I was missing, as more of the web moved to HTTPS. But those trying it out now for the first time, they certainly do. It's a little hard to judge perf here because there are a lot of factors (and IANAE) like DNS cached and so on, but surely less handshakes or whatnot improve speed. I can literally see the difference, so it's not insignificant: but it's not also "every page every time"

There was a reddit post in the last week (can't re-find it yet), where someone said they had tried the user.js and it was great except things were a bit slow: and someone else pointed out three things: asm, wasm, SSL session IDs. And then someone else pointed out RFP can slow some things down as well. WASM I don't care about (0.2% of sites). ASM is much the same (security). And RFP is sacrosanct. But it made me think about SSL session ids.

generally speaking, the order of priority would be Security (e.g. WASM) trumps Tracking/Privacy which trumps Fingerprinting, but of course breakage and perf and usability need to be considered as well. As per usual, each item needs to be weighed up in some sort of threat-risk assessment matrix of pros/cons.

The fingerprinting is the least concern. Very few would be blocking ssl session ids. My gut reaction is that the payoff for the server to track this is too small. On the other hand, they would be far more likely to use the session ID itself (for linkifying) if it were offered up

It's the tracking part that is worrisome. I do get that by disabling session ids altogether, you remove the ability of servers to use that, including the way it leaks the old id upon resumption, so a when a new id is pushed by the server, it can be linked to the old one: prolongation attack. And to be sure, servers will (and do?) leverage this. The paper/pdf mentions a bunch of Alexa top sites and the expiry lengths they request (AFAIK Firefox respects a max of 24hrs), and while a lot set only 10 minutes or whatever, aholes like Facebook ask for 2 days or something. Lets just say it's definitely being used and will become more frequently abused for tracking.

The pdf is linked in [3] https://arxiv.org/abs/1810.07304

So to be sure, if we make the pref inactive (and users reset it), then helping to track via this method will be there on some sites. But none of that matters in a session unless you can sanitize everything, including your IP (although an IP can be multiple users). So I actually do not see this as a very useful pref any more. It's also a good time to make it inactive now that non FPI users are also isolating SSL session ids.

If you use Temporary Containers in a hardened setup (which then should sanitize almost everything), then the pref makes no sense either. And if you're not using containers, then how are you sanitizing (extensions alone aren't enough). Now I do get that the more you sanitize and the harder you make the tracking/linking .. the better: anything to make the bastards work for it: but I also think that this pref is creating a false sense of "privacy". Instead we should be telling users to fire up a one-off PB mode window, or learn to close sessions or use multiple profiles/browsers etc = more about OpSec than anything technical.

So that's my story: I just think it's time we turned this pref inactive and updated expectations: For me, having the pref active = false sense of privacy vs having the pref inactive = better FP, better perf: and more importantly, we're not giving the impression that Firefox can really be used this way to defeat repeat visits per session - not even Tor Browser does that!

gitthehubs commented 3 years ago

@Thorin-Oakenpants

I would like to address to you that your following comment is not correct:

not even Tor bothers: although you can request a new circuit AFTER you loaded it, and WHILE it's still open: the purpose being blockages, not to sanitize anything. Even when changing circuits, there is no sanitizing of e.g. persistent web storage

In the settings information text you added the link: https://bugzilla.mozilla.org/967977 I will quote the first comment:

There is a pref to disable TLS session tickets (security.enable_tls_session_tickets), but there is no corresponding pref for SSL3 Session IDs. In Tor Browser, we simply patched NSS directly to hardcode them to off, as we do not want to enable the additional tracking facilitated by these identifiers. This patch is against FF24ESR.

If I understand this correct, in the Tor Browser this is hardcoded and not controlled by the setting security.ssl.disable_session_identifiers , which apparently is only for Firefox.

I also have the following link for you: https://www.ssl.com/article/tracking-users-with-tls/ Quote:

Am I vulnerable? Protocol-wise, all TLS versions (including the latest TLS 1.3) provide a mechanism for session resumption, meaning users could be tracked using this technique, regardless of TLS version. Additionally, out of 48 browsers tested in the paper, only 3 were found to have disabled TLS session resumption. These browsers are: JonDoBrowser Tor Browser Orbot (for mobile)

The site also made a test: https://www.ssllabs.com/ssltest/viewMyClient.html (note: the test runs on port 8443 and need some additinals ports as well to complete all tests, make sure your firewall allows this, only port 8443 is needed to test session tickets) If you do this test with the Tor Browser(current 10.0.10) you will see the Tor Browser does not support session resumption:

Session tickets | No

I assume the reason why Tor Browser does not support session resumption is that if the tor circuit changes while browsing on a site it cannot be link to the same user by the tls session.

And you also say:

The fingerprinting is the least concern. I doubt servers bother to analyze logs and track IPs that repeatedly bombard with SSL session ID tickets requests in order to link traffic: but it's certainly plausible.

As the ssl test shows, it can easily be tested and used for fingerprinting. But is it used in the real world? If used by for example advertising than anti-fingerprinting or ad-blockers will probably block this anyway.

So if tracking is prioritized over fingerprinting than I think you should leave the setting enabled, unless you think the performance impact is too big.

Well.... new things to think about. :)

Thorin-Oakenpants commented 3 years ago

not even Tor bothers

by that I meant that they are not bothering to hide repeat visits per session: which is what the parent bullet point says and the example shows. And if you do a new circuit for example, this doesn't even sanitize all persistent WEB data: like localStorage

FP

Yeah, sorry... not sure what I was thinking. Of course a single check is all that is needed to determine if it's supported. If anything, this makes the FP argument ever so slightly stronger, esp since it's a passive FP

This patch is against FF24ESR

That's a long time ago. Since then we are now TLS1.2 minimum, and FF has been radically changed. Without wanting to put any words in anyone else's mouths - my understanding was that TB didn't do this (but see your test) - because FPI. And when I asked Arthur about it several years ago, he said basically what I said in OP: that it's covered by FPI and repeat visits within a session are out of scope

I assume the reason why Tor Browser does not support session resumption is that if the tor circuit changes while browsing on a site it cannot be link to the same user by the tls session

Why would the tor circuit change while browsing (excluding manually doing it)? IDK, Can it even do that or would it time out? IDK. Sounds like that scenario carries other risks. The fact of the matter is that there is no sanitizing until the session ends: so therefore talk all you like about the exit node changing .. but other SIMPLE tracking still remains: so I don't buy that as the reason here

@gitthehubs , thanks for the digging and more items to ponder, and I might ask the tor devs a couple of questions

Thorin-Oakenpants commented 3 years ago

Just to make it perfectly clear that Tor Browser does not support isolating/hiding repeat visits per session

circuit

tl;dr: Firefox and TB are simply not geared to do it: although in FF you could use one off PB windows or TC-hardened and jiggle your IP in between them or something

gitthehubs commented 3 years ago

@Thorin-Oakenpants I know the quoted text is 7 years old, but I got the link from your own comments on that setting in the user.js. :) Anyway, the age of that comment does not really matter, it's the behaviour of the Tor Browser in this case and the ssl site and test confirms Tor Browser does not support session tickets/session resumption. So that's the reality and what matters. :)

Tor Browser changes circuits all the time, not sure what the exact criteria is, but it can be within a minute if you quickly browse a site from one link to another for testing purposes, so yes that is within the same site visits. The main reason I can come up to would be anonimity so even an exit node cannot collect too much information about a tor user. To be honest I have no idea what exactly happens with the local cache, like cookies and so on, that will of course not be refreshed for as far as I know, else you would have log in problems. So of course a site can track you on that, but the tor network make you anonymous on that and the tor circuit changes make you more anonymous for the tor exit nodes, which eventually should not be trusted also. I must say, but I could be wrong, tor behaviour has changed during the years, so a comment on the behaviour in the past could be outdated, not saying it is, but could be, just to keep in mind.

Thorin-Oakenpants commented 3 years ago

Well, it used to be circuits changed every 10 minutes (but I didn't think it applied to a current domain?), but AFAIK that was dropped a while ago, as each eTLD+1 is a different exit node: you can see this for yourself

gitthehubs commented 3 years ago

@Thorin-Oakenpants I use tor for many years now on a daily basis. Not saying I'm a tor-expert :) , but I do know a little bit about tor. I tested it yesterday(v10.0.10) to be 100% sure before I made the comment, I browsed to a site and went from one article to another article on that site and saw tor changing circuits. I must say tor circuit behaviour is different today if I do the same test again on the same site as yesterday. But what I said, I notice tors behaviour is not really constant, it can vary per day and per Tor Browser version. Not sure what the cause of that is, maybe the different tor versions tor nodes run, I have seen a page where they showed all tor version tor nodes run and there were maybe 6 different versions tor nodes run, from 3.x to 4.x. So maybe your tor circuit behaviour can change depending on your tor entry nodes?? Just guessing... I know they say your tor guard entry node can be the same for months, sometimes I do have the same guard entry node for several days and sometimes it can change per day.

Anyway, not sure if we should really discuss tor in detail :) , all you wanted is a discussion about the preference user_pref("security.ssl.disable_session_identifiers", true); . My comment was primairly to a wrong assumption about tor, tor does not support session resumption. And whatever you may decide, personally I will leave the preference at true. :)

Thorin-Oakenpants commented 3 years ago

My comment was primairly to a wrong assumption about tor, tor does not support session resumption

no worries: it's just a discussion :) all comments welcome: sorry if it seems like I'm rubbishing anything you said

Duly noted and well spotted - thanks 👍 I edited OP the other day. I'm not an expert on Tor circuits either. I am going to email arma/sysrqb about it (session ids) with a few questions (still mulling over whether or not to: I don't want to waste their time: but I have meet them in person before and they do know me: and sysrqb and gk (edit: and roger) are very approachable)

So it basically comes down to: what does this actually achieve?: answer: it removes a clear means of first-party in-session tracking, but probably puts you into a tiny group (if FPed that way: Tor users don't care: they're all in the same boat) and does not address the elephants in the room: full sanitizing (which even TB doesn't do) and IPs.

My analysis in OP still stands: I think the pref is pretty much useless in any FF setup and gives a false sense of "privacy". One elephant: eliminating other tracking = use TC-hardened or one-off PB windows, makes the pref pointless as well. And FF is not designed to flip IP addresses at will.

crssi commented 3 years ago

user_pref("security.ssl.disable_session_identifiers", true); will break USB secure tokens. Not saying that it should be changed or whatever, but to make a comment there in the 1204 .

I can retest in the next days again, if needed.

Thorin-Oakenpants commented 3 years ago

That's a good point crssi: I hadn't considered that breakage could occur

rusty-snake commented 3 years ago

I'll jump in and tell you what I'm doing. :smile: I've have it as false in my overrides since I use this user.js because

Thorin-Oakenpants commented 3 years ago

it's cleared by TC

does TC clear SSL session ids?

rusty-snake commented 3 years ago

If I understand https://bugzilla.mozilla.org/show_bug.cgi?id=1316283 right*, it is isolate by userContectId and therefore cleared by TC.

* This is all a bit confusing, ssl session tickets vs. tls session resumption and I need some sleep :sleeping: .

crssi commented 3 years ago

does TC clear SSL session ids?

AFAIK yes. But "I would not bet on" anything these days until someone smarter than me tests it thoroughly. 😉 I am keeping it false for "years" now, due to USB secure token breakages.

Thorin-Oakenpants commented 3 years ago

I was trying to find the API that TC uses to clear everything, but it doesn't really matter.

I know what the answer should be: cut the lifespan to 10 minutes

gitthehubs commented 3 years ago

@Thorin-Oakenpants

does TC clear SSL session ids?

Session ids are stores in cookies, so if all cookies of a container are cleared the session id is cleared too.

The Ultimate Guide to Session Hijacking aka Cookie Hijacking https://www.thesslstore.com/blog/the-ultimate-guide-to-session-hijacking-aka-cookie-hijacking/

gitthehubs commented 3 years ago

@rusty-snake

  • This is all a bit confusing, ssl session tickets vs. tls session resumption and I need some sleep 😴 .

Maybe this article will help you understand it a little bit better: TLS Session Resumption: Full-speed and Secure https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/

Thorin-Oakenpants commented 3 years ago

Hmmm .. currently PB mode windows also do not support ssl session ids, just tested it in nightly: I never knew that (note TB is in permanent PB mode) - that kinda makes the passive FP a lot less damaging. see 1101528

Thorin-Oakenpants commented 3 years ago

Session ids are stores in cookies, so if all cookies of a container are cleared the session id is cleared too.

You're confusing login sessions with SSLSessionCache - which is/should-be RAM only client side

Here's a couple of links

Thorin-Oakenpants commented 3 years ago

OK, so I was right (I knew it) that TB doesn't do anything for SSL session ids. This is practically the same answer Arthur gave me years ago: its not an issue as it is covered by FPI (and mention repeat in-session visits and you get blank stares)

gk-says

edit: links for you [1] https://gitlab.torproject.org/legacy/trac/-/issues/17252 [2] https://gitlab.torproject.org/legacy/trac/-/issues/17252#note_2201663

gitthehubs commented 3 years ago

@Thorin-Oakenpants

I've never thought of testing tls session resunption in PB.. so not supporting tls session resumption is not a TB property, but just a PB property.

Thorin-Oakenpants commented 3 years ago

Almost three weeks later .. thanks all two three of you for participating (and KOLANICH for the thumbs up)