Opened 2 years ago

Last modified 2 years ago

#21418 new enhancement

New Tor Browser http response header, for high security websites

Reported by: micahlee Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


When someone uses Tor Browser to load a SecureDrop website, if javascript is enabled, it recommends that they disable it. But at the moment, there are some big UX problems with how it's done: It's a big scary red warning that's displayed to nearly all users, and the instructions are out-of-date (they tell you to disable JS using NoScript instead of the Tor Browser security settings slider). Overall, it's scary and confusing, and tells _everyone_ to jump through hoops.

Here's some of the discussion about this on the SecureDrop issue tracker:

The rationale behind telling users to disable javascript is because the SecureDrop server itself is part of the threat model. If someone successfully hacks a SecureDrop server, they can then serve Tor Browser exploits to all of its users to deanonymize them (similar to the Freedom Hosting attack), and high security mode reduces this attack service a lot.

I'd like to propose a new custom http response header that Tor Browser watches for: X-Tor-High-Security: 1. If you load a website with this header set, no matter what the Tor Browser security slider is currently set to, it should treat that tab as if the slider were set to high.

This would also be very useful for anyone running websites where they include themselves in the threat model, such as Tor-based email providers.

Child Tickets

Change History (5)

comment:1 Changed 2 years ago by micahlee

Component: - Select a componentApplications/Tor Browser
Owner: set to tbb-team

comment:2 Changed 2 years ago by mcs

Cc: brade mcs added

comment:3 Changed 2 years ago by micahlee

Type: defectenhancement

comment:4 Changed 2 years ago by tom

Is a header the right choice for this? On the surface, I kind of like the ability for a website to opt-in to stricter security controls but the threat model is odd.

If it's a HTTP Header that applies per-request, the attacker has hacked the server or the network, but not completely otherwise they could remove or disable the header.

If it's some sort of persistent mechanism (for example: a HTTP Header that gets remembered with max-age) then we're presuming the HTTP Server is trustable at one point in time and then gets compromised later.

That second one seems a lot more reasonable to me than just a per-response header.

It does; however, introduce the state problem - you don't actually want to remember state in Tor Browser so we would have to solve that problem.

I would note that this really applies more for the other features of the Tor Browser security slider than Javascript. You can effectively disable javascript entirely using Content Security Policy with _is_ a per-response header that Tor Browser already supports.

comment:5 Changed 2 years ago by micahlee

Tom, that's a very good point about how after the attacker hacks a web server they can change the response headers.

It seems like, to accomplish this for SecureDrop servers, Tor Browser would have to bundle some sort of Tor-High-Security preload list of domains, similar to the HSTS preload list. And, of course, start maintaining that list.

Note: See TracTickets for help on using tickets.