Securedrop: Purple Tor bar still showing in Tor

[ninavizz]

Description

I am being told to use Tor when I am using Tor.

Steps to Reproduce

Lookup instance using Tor, on a Mac.

Expected Behavior

No purple bar.

Actual Behavior

Purple bar.

Comments

Not sure if an issue already exists for this, but I do recall chatting w/ @rmol and @zenmonkeykstop about it.

Suggestions to fix, any other relevant information

This will really suck for sources. I'd rather not do the purple bar or any "You are not using Tor" kind of dictatorial intercept, if we cannot get it right. A lighter "Hey, are you using Tor?" y/n binary question or an interstitial, could be a better option.

[eloquence]

Note that I'm unable to reproduce this on Ubuntu/TBB 9.0.1, so this may be a platform-specific issue.

[DrGFreeman]

If it can help here's a few quick checks I made (all using Tor Browser 9.0.2):

Dev VM

(in a Ubuntu VM), as of 6c46568a6d58e26bcd76647c3c1ea7a2a4546871:

Security setting: Standard

Security setting: Safer and Safest (same behavior)

### Windows 10
(in a VM)

Security setting: Standard

Security setting: Safer

Security setting: Safest

Ubuntu 18.04

Security setting: Standard

Security setting: Safer

Security setting: Safest

Summary:

In Ubuntu, Dev environment, the "Security settings" warning is displayed at Standard level only.
In Ubuntu, ABC instance (1.1.0), the "Security settings" warning is displayed at Standard and Safer levels.
In Windows 10, ABC instance (1.1.0), the "Recommended to use Tor Browser" warning is displayed at both Standard and Safer levels.

I don't have a Mac to test but from @ninavizz's screenshot, the "Recommended to use Tor Browser" warning is displayed even at Safest level.

Additional note, I noticed the "warning icon" text in the banner when the "Security settings" warning is displayed, both in the Dev VM and on the ABC instance when using Ubuntu. The CBC instance (also 1.1.0) displays the icon properly:

[rocodes]

Repro'd on MacOS if browser settings are at Safe and Safer (but not Safest).

[rocodes]

See https://github.com/freedomofpress/securedrop/blob/2d066eb4dfe569973418ebe372c3f7f128e91d7c/securedrop/static/js/source.js
The UA regex is not matching correctly, leading to the errant "switch to TB" message being displayed.
Example nonmatching UA: User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Firefox/68.0

[eloquence]

It seems to me that the "Is this Tor or just Firefox" detection code is inherently fragile. There's a strong case for detecting browsers known to support Tor without its built-in security protections (e.g., Brave), but should we narrow the detection logic here to make it more maintainable?

[rocodes]

(relevant: #3793 and anywhere else this same checking logic is used)

[eloquence]

@rocodes will be doing some research doing the 12/5-12/18 sprint:

• Is there a clean resolution that will work well across platforms? (If so, a PR would be lovely :)
• What are usptream plans regarding UA reporting in Tor Browser?
• Based on the above, what should our long term approach be to this detection logic?

We can then discuss more as a team as needed.

[rocodes]

TB UAS Relevant Info

• Tor's design and implementation doc 2019 ("Specific Fingerprinting defences in Tor Browser" s.17 User Agent/HTTP headers). Relevant section:
  > Design Goal: All Tor Browser users MUST provide websites with an identical user agent and HTTP header set for a given request type. We omit the Firefox minor revision, and report a popular Windows platform. If the software is kept up to date, these headers should remain identical across the population even when updated.
• The above design goal is not borne out in practice, due to changes in Firefox (particularly with privacy.resistFingerprinting) that result in bad UX on some platforms (mobile, macOS), but there is still an attempt to standardize UAS to a few variants.
• The most recent info I could find for Tor Browser is from 15 months ago:
  > When [privacy.resistFingerprinting] is on, http header is spoofed according to a 2-tuple (windows on pc, and android on mobile). Entry in javascript navigator object is spoofed according to [a] 4-tuple [...] (android, linux, mac, windows). source

Relevant tickets

• Above and this one on navigator.userAgent fingerprinting
• Why this is so dependent on what Firefox is doing. TL;DR privacy.resistFingerprinting affects whether platform is reported or not on Firefox Here is the rationale

A bit about mobile

This section might not be as relevant because we aren't really mobile-optimized anyway, but it's good to know.

• Tor Browser mobile Android has a few different behaviours, but TL;DR is you can expect a UAS reporting Android or Linux
• Onion Browser (iOS) default UAS looks like this: "Mozilla/5.0 (iPhone; CPU iPhone OS 8_4_1 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12H321 Safari/600.1.4", but the user agent string also appears to be customizable on Onion Browser, meaning that _if_ people are using OnionBrowser and change the UAS, we can't help em.
• I've filed a ticket with OnionBrowser asking if they'd be willing to report a more generic UAS instead of directly reporting a user's OS version

Detecting Tor now

• We could theoretically change our regex to something like /Mozilla\/5\.0 \((Windows NT 10\.0|Windows NT 6\.1||X11; Linux x86_64|Macintosh; Intel Mac OS X 10\.13|Windows NT 10\.0; Win64; x64|Windows NT 6\.1; Win64; x64); rv:[0-9]{2}\.0\) Gecko\/20100101 Firefox\/([0-9]{2})\.0/; which should (?) match all TB8/older and TB9 users, but this needs testing and is getting unwieldy. We could make it simpler if we don't need to match users who are on a non-up-to-date version of Tor Browser.
• We could stop checking UAS, and rely only on other methods to determine the browser (this is what I think makes most sense): lack of canvas access, disabling webgl, GMT timezone, window margins are zero (we currently check the latter 2), possibly other identifiers TBD. (I kinda ruled out regularly pulling a list of Tor exit node IP addresses as a strategy, I think not worth hassle)
• Roger's comments on detecting Tor Browser, noting these are over 6 years old, seem like the best way to go:
  > Torbutton, and the changes in Tor Browser, are designed to make all Tor users blend together, but they're not designed to make every Tor user indistinguishable from all other normal web browsers. So you can probably build a signature based on the differences that the Tor Browser introduces (tells you the time zone is GMT, doesn't answer certain JavaScript queries, doesn't answer certain history requests, etc) to make a pretty good Tor user recognizer.

What next

• I check in with @harrislapiroff on a few more non-UAS-related ways of identifying Tor Browser
• We could update the UAS regex we have now and also figure out a better method to check
• We could stop checking, display a generic "We really hope you're on Tor Browser...." message all the time on our website, and not display any such message on source interface pages (if it's an .onion URL, either they are using TB to access it, or they are making an active choice to compromise their security by using Tor in a non-standard way and we can't really control that....)

Levity

https://webaim.org/blog/user-agent-string-history/

[redshiftzero]

really nice writeup, thanks!

this is what I think makes most sense

hmm yeah that makes sense, do you know how clean selecting by just GMT timezone and window margins are zero is? (i.e. if we remove the UserAgent regex)

[rocodes]

That's what we do now (plus the regex), but I have yet to test if that is sufficient. The window margins were always a pretty good hint, but I haven't looked into if letterboxing changes that at all, or if those two indicators alone are sufficient. bit of testing is my next step.

[rocodes]

Of interest:
https://ghacksuserjs.github.io/TorZillaPrint/TorZillaPrint.html for looking at what kind of information is shared by Tor Browser.

For example, on security slider setting "Safer," my http user agent string is blank (Tor Browser will spoof it to look like Windows/FF), but navigator.userAgent correctly reports when I am on a Mac.

[rocodes]

Updated opinion: I think I vote to stop trying to detect Tor browser and display a generic "we hope you're on Tor browser" message.

Rationale: Firefox's resistFingerPrinting incorporates more and more Tor features, and for users who enable it, all of our checks (window size, timezone, canvas, spoofed UAS, etc) will be exactly the same as what would be reported on Tor browser. So at minimum, we'd report incorrectly for Firefox users who have enabled this feature unless we were also checking IP addresses (then we'd have a better chance of being right, but it wouldn't be foolproof). If this ever becomes a default setting, we will be incorrect about all FF users.

If we continue to use UAS as a means of trying to identify Tor, we will have to keep that regex updated as Tor updates, which will lead to brief breakage every time the spoofed UAS is changed. Seems like too much fuss for this feature.

For the short term I will put in a PR to update the regex, which will match updated versions of Tor browser on all platforms (with the above caveat of false positives on Firefox with resistFingerprinting), but long term this is my suggestion.

Other opinions welcome/encouraged though.

[redshiftzero]

👍 to updating the regex for now. Another change (could be done separately) that would be nice is simplification of the regex to remove support for older version of Tor Browser, provided we modify the text slightly replacing "Tor Browser" with "latest Tor Browser" (and double checking that the instructions we link to in the banner are consistent with the update case). We don't actually want people to use old versions of Tor Browser either, so this seems like a win all around.

Regarding a broader change, I would be amenable to a generic message “Ensure you are using the latest version of Tor Browser for your security” or similar. What do you think about a simple message like that @ninavizz? The hazard is that users might be confused - “but am I using Tor browser!” - but if we can find the right wording I think this could be an acceptable tradeoff.

If finding acceptable language there is not possible, then I think we’ll want to preserve _some_ kind of browser detection logic to handle the cases where sources might be using Tor but not Tor Browser. This will happen due to the increasing popularity of e.g. Brave Tor tabs or other browsers that enables access to onion services but do not yet have sufficient leak proofing for a sensitive use case like SecureDrop. See relevant discussion in Brave's community forum about the User-Agent - if they keep the UA Chromium-like and not Firefox-like then we will definitely be able to encourage Brave users to get regular Tor Browser until their tabs are at parity in terms of leakproofing protection with Tor Browser, so that's good news.

If we _do_ continue to preserve the browser detection, regarding the breakage in production:

• SecureDrop’s regular releases generally coincide with Tor Browser/Tails releases, so we could incorporate testing using the Tor Browser alphas during our QA period.
• Another option is to improve our automated tests. We have functional test coverage of the banner on Linux. We could run just those couple of tests on other platforms (this is supported by CircleCI), which I think would have caught this issue.

[eloquence]

Regarding a broader change, I would be amenable to a generic message “Ensure you are using the latest version of Tor Browser for your security” or similar

Under what circumstances would that generic message be shown? Always, or only if there is some mismatch? If always, I worry a little bit about message fatigue here.

How about eliminating attempts to detect Tor Browser itself, and focusing only on detecting known methods for accessing .onion services which we do not currently recommend (e.g., Brave, Orfox [already implemented]) _and_ which we can detect with sufficient reliability?