Plugging TLS 1.3 user tracking across sessions (clear net > VPN)

[RainmakerRaw]

I have recently migrated (most of) my user.js to this excellent repo, but noticed I had to bring a few extra tweaks across with me from my old version. I'm especially concerned about the abilities provided by session resumption and weakened key regnogiation in TLS 1.3, which makes it possible to track users persistently across browser sessions - even from clear net to VPN (or ToR) and back again).

This was first brought to my attention a couple of years ago, in a PIA blog post by cryptographer Derek Zimmer. The four recommended Firefox tweaks to plug this tracking vector are:

user_pref("privacy.firstparty.isolate", true):
user_pref("security.ssl.disable_session_identifiers", true);
user_pref("security.ssl.enable_false_start", false);
user_pref("security.tls.enable_0rtt_data", false);

I notice this repo's user.js enables two of those options, but not the other (bottom) two; false_start and 0rtt_data. Is there any way to consider adding them to the default list (even if just the 'strict' file)?

[Thorin-Oakenpants]

arkenfox/user.js#536

quoting me

OK, @ tomrittervg says (via email) the article is so riddled with errors that he doesn't even want to begin debunking it for fear that he'll have to correct em all

quoting tom ritter in the above issue

The crux of it - that TLS features like 0rtt and Session Resumption can be used as persistent identifiers - is true. But FPI isolates them. (And doesn't block requests as the article says!) And Private Browsing Mode also has the expected protections.

False start has nothing to do with persistent identifiers.

and also

False Start is a hack-optimization for TLS 1.2 and below which sends application data before the TLS Handshake is completed. It has some compatibility problems, because this behavior goes against spec, but it works in the overwhelming percentage of cases. However I believe Google still disabled it for the vast minority of problems it caused.

The security concern is that an attacker could downgrade the negotiation so you wind up encrypting data with a weak ciphersuite that could lead to decryption. Thus false start is prohibited if a weak cipher is negotiated.

From memory, TLS 1.3 codifies false start into the normal operation of the protocol.

Unless you are facing compatibility problems with a weird network appliance that can't handle false start; there is no reason to disable it.

tom is a security dev at mozilla, who also does a lot of work for tor browser, and he worked on tor uplift, etc

I'll take tom's assessment over almost anyone else, but especially a scaremongering blog post on a site that sells privacy services (no idea of the relationship of the blog author to PIA: not insinuating anything there if he's independent)

---

to this excellent repo

This next paragraph is not meant as a reflection on pyllyukko et al and their work, it's just a statement that indicates that it's not been kept up to date (we all have other priorities in life besides maintaining a repo and dedicating free time). Personally, I think the repo should at least add something to the readme and to the user.js itself that it's no longer maintained (but that's not my call)

Over a third of the prefs are deprecated even for ESR68, and there has been practically no changes or upkeep for prefs for almost three years - see privacytools/privacytools.io#1240 (which was Aug last year)

[RainmakerRaw]

Thanks for the reasoned and enlightening reply. Have you any better suggestion for a maintained list then? ghacks?

Edit: Never mind, I just realised who you are lol. Thanks again for the input, I'm working my way through your user.js now to adjust it to my needs.

[Thorin-Oakenpants]

Well, it (ghacks user.js) is my repo, so I'm probably biased. That said, I am not aware of anyone else doing what we do.

Myself and earthlng do almost of the work, with good input from some regular knowledgeable people, and we haven't missed dissecting any pref diffs since moving to github.

[RainmakerRaw]

Thanks again, Thorin. I have my (your) new file in place and everything I need working works (i.e. skipping x-origin-referer so iCloud works). Just one little side question if I may, since we're here. I have disabled allowing pages to choose their own faults as per recommendation (to reduce font fingerprinting). However the default Times and Courier (macOS) are damned ugly. Would it be detrimental to change my default fonts to - say - Roboto Slab and Fira Sans, still disallowing change? That seems like it'd stand out like a sore thumb to fingerprinters but then my installed fontbase is already unique in itself, so?...

[Thorin-Oakenpants]

You should stick to the default fonts if you're worried about FPing, since fonts affect all sorts of measurements like default line heights, etc. Instead

• override browser.display.use_document_fonts = 1
• set font.system.whitelist to the same value as Tor Browser on your Mac
  • if you add it to the overrides, make sure it doesn't contain non ANSI chars (pretty sure the Mac list doesn't) - edit: or make the user.js UTF-8 ? IDK
  • note the TB list probably also includes the bundled fonts (I think they bundle the same 5 Noto Sans as they do in windows)

At least that way, any font enumeration will only be limited to those few known mac fonts

[RainmakerRaw]

Again, thank you!

[Thorin-Oakenpants]

@RainmakerRaw oooh, almost forgot .. make sure to include Firefox's bundled emoji font in your whitelist - it's Twemoji Mozilla