Project

General

Profile

Feature #5362

Evaluate web fingerprint

Added by Tails over 6 years ago. Updated 3 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Security Audit
Blueprint:
Starter:
No
Affected tool:
Browser

Description

Now that we use Torbrowser patches (#5798), we can reconsider the browser fingerprinting issue.

We should evaluate the Tails web browser fingerprint.

  • Extensions: FoxyProxy, Cookie Monster, You tube video downloader, download manager (not implemented yet), Adblock.
  • Would we be ready to stick to or synchronize our add-ons with Torbrowser? (e.g Adblock is useful)
  • "Tor Browser disabling Javascript anonymity set reduction" thread on tor-talk

team: jvoisin, spriver?


Related issues

Related to Tails - Feature #5706: Harmonize our Tor Browser config with TBB Resolved

Associated revisions

Revision 3540b677 (diff)
Added by intrigeri 3 months ago

Drop NoScript customization that makes our web fingerprint diverge from Tor Browser's (refs: #5362)

There's no strong reason to handle Google Analytics differently than all
other trackers. The security model of Tor Browser does not rely on
arbitrary blocking of specific trackers, but instead on isolating
different web activities from each other.

History

#1 Updated by BitingBird over 5 years ago

  • Subject changed from evaluate web fingerprint to Evaluate web fingerprint
  • Description updated (diff)
  • Category set to 176
  • Starter set to No

#2 Updated by BitingBird over 5 years ago

  • Related to Feature #5706: Harmonize our Tor Browser config with TBB added

#3 Updated by sajolida over 4 years ago

  • Assignee set to jvoisin

#4 Updated by sajolida over 4 years ago

  • Target version changed from Hardening_M1 to 2016

#5 Updated by jvoisin about 4 years ago

Currently, the main issue that I see is AdBlock Plus, because it can super-easily be detected. Also, cookies blocking issued by CookieMonster can be detected by the website which has its cookies blocked.

Those are the two current main culprits in regard to fingerprinting that can be used to tell apart Tails and TBB users, and I don't see any easy way to fix this, other than pushing either removing those extensions from Tails, or to push them into the TBB.

#6 Updated by intrigeri about 4 years ago

Also, cokkies blocking issueed by CookieMonster can be detected by the website which has its cookies blocked.

We're not shipping CookieMonster since Tails 0.23.

#7 Updated by Dr_Whax over 3 years ago

  • Description updated (diff)
  • Priority changed from Normal to Elevated

#8 Updated by intrigeri over 3 years ago

  • Priority changed from Elevated to Normal

(As long as this stays on our roadmap with a clear target year, we don't need to bump priority.)

#9 Updated by intrigeri almost 3 years ago

  • Target version changed from 2016 to 2017

I wanted to mark this ticket as blocked by the "Ship a time machine in Tails" one, but could not find it, so let's instead postpone :)

#10 Updated by cypherpunks almost 3 years ago

I assume the threat model is only for people who have JavaScript disabled? It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:
  • Tails currently, or will eventually, block access to /dev/dri/ through its AppArmor policy for security reasons.
  • Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.
  • The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.

I just want to confirm that the assumption is not that (active) fingerprinting can be fooled into being confident that a given browser is running on Tails, if JavaScript is enabled. Passive fingerprinting or scriptless fingerprinting probably won't be able to tell after plugins etc. are synchronized.

#11 Updated by intrigeri almost 3 years ago

I assume the threat model is only for people who have JavaScript disabled?

No, it's about the default settings, and web fingerprinting by network attackers and admins of visited web sites.

It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:

  • Tails currently, or will eventually, block access to /dev/dri/ through its AppArmor policy for security reasons.

Can you please clarify how this can be detected by the adversaries we have in mind?

  • Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.

Care to clarify how this can be done?

  • The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.

Indeed, I expect that once we ship to 64-bit this will remove one thing that makes Tails different from most other Tor Browsers.

#12 Updated by cypherpunks almost 3 years ago

intrigeri wrote:

I assume the threat model is only for people who have JavaScript disabled?

No, it's about the default settings, and web fingerprinting by network attackers and admins of visited web sites.

For reference, the adversaries I am referring to are those who are intentionally trying to detect that a given Tor Browser user is also a Tails user, rather than an adversary who is retroactively checking the logs of another fingerprinting adversary (e.g. CloudFlare), or nosy sysadmins who have set nginx to an excessively verbose loglevel.

It is easy to tell if someone is using Tails (even with Adblock Plus removed, etc.) if JavaScript is enabled, for a few reasons:

  • Tails currently, or will eventually, block access to /dev/dri/ through its AppArmor policy for security reasons.

Can you please clarify how this can be detected by the adversaries we have in mind?

There are some CSS elements which are accelerated using hardware acceleration (unrelated to WebGL hardware acceleration), the kind which is not turned off just by disabling "enable hardware acceleration" in the UI, I believe. I don't remember any specifics off the top of my head. Basically, performance fingerprinting of specific functionality, though I would bet that there are plenty of other ways to remotely detect whether or not Firefox has access to DRI nodes.

Of course, access to the DRI nodes can also make fingerprinting worse, due to GPU clock fingerprinting and other techniques, so it's not like it's just a trade-off between security and fingerprintability.

  • Math library fingerprinting can detect that Debian stable is likely in use, which points heuristically to Tails.

Care to clarify how this can be done?

High precision math libraries on different systems will give different results for some functions which can identify the operating system, and even different math library versions. See https://people.torproject.org/~gk/misc/MathHighPrecisionAPI.html for a PoC, and https://trac.torproject.org/projects/tor/ticket/13018 for the bug report.

It was suggested by mikeperry to ship the same version of libm.so for all their Linux bundles in that bug report to mitigate this fingerprinting vector, in which case it would limit an adversary to only be able to tell that the Tor Browser user is a Linux user, but not that they are using the specific math libraries used by the version of Debian which Tails is based on at any given point in time.

  • The browser build is 32 bit (I believe this can be fingerprinted?), though Tails will use a 64 bit userland soon.

Indeed, I expect that once we ship to 64-bit this will remove one thing that makes Tails different from most other Tor Browsers.

Which also means Tails will be compatible with the official Tor Browser Sandbox which Yawning Angel made! Though that's for another ticket (and plenty of testing).

#13 Updated by cypherpunks almost 3 years ago

Oh yeah, and of course there's the fact that the date format which JavaScript provides gives away that the platform is Linux, see https://trac.torproject.org/projects/tor/ticket/15473. Additionally, the list of included/whitelisted fonts differ between Linux and Windows (e.g. MSPGothic is included under Windows, but cannot be included under Linux for licensing reasons. See https://trac.torproject.org/projects/tor/ticket/20820 for a problem caused by the different font support between platforms). There are also HTML5 features which are platform-specific (see https://trac.torproject.org/projects/tor/ticket/13543). While these don't specifically point to the user being a Tails user, it does reduce the anonymity set a bit (i.e. they can only hide among other Linux users, not among all users of Tor Browser).

It might also be possible to use resource:// URIs to discover whether or not a user is a Tails user, if the browser configs exist in any different location, or have been changed in any way from the upstream configs (e.g. current Tails disables autoupdate, which is detectable as these files are not protected like resources under file://). The files can be read line by line, checksummed, uploaded remotely, etc. See https://browserleaks.com/firefox for an experimental PoC, and https://trac.torproject.org/projects/tor/ticket/8725 for the ticket.

#14 Updated by Kurtis almost 3 years ago

Is the fact that the list of included/whitelisted fonts differs between Tor Browser users in Linux and Windows even solvable? I'm assuming that the amount of preloaded fonts on the OS don't have enough overlap between the two operating systems. I hadn't heard of this issue before, but javascript on, this site demos how JS can easily determine what kind of fonts your system has preloaded. https://arthuredelstein.github.io/tordemos/enumerate-fonts.html

Even with TBB's font.system.whitelist strategy in place, sites can use JS to determine what operating system you are using, no? Can this be minimized in any way?

#15 Updated by BitingBird over 2 years ago

  • Assignee deleted (jvoisin)
  • Target version deleted (2017)

#16 Updated by intrigeri over 1 year ago

  • Type of work changed from Research to Security Audit

Let's assume that we don't try to hide the platform (Tor Browser mostly gave up on that, see User-Agent in Tor Browser 8) and probably the fact we're running Debian.
I've taken a look at our current delta and I think the main things that make Tor Browser in Tails different than Tor Browser on another Debian system are:

  • uBlock Origin → the project has spoken and wants to keep it
  • pref("noscript.untrusted", "google-analytics.com"); → not sure why we still have this, I'm in favor of removing this part of our delta, that probably causes more problems than it solves

It's also possible that some restrictions (e.g. to system-wide ressources) of our AppArmor policy make the browser's fingerprint different. It would be interesting to research this.

But I'm not an expert at these things and IMO someone better skilled should look into our actual fingerprint, from an adversarial PoV => updating type of work.

#17 Updated by intrigeri 3 months ago

  • Status changed from Confirmed to In Progress

Also available in: Atom PDF