HTTPS-E conflicts with NoScript in Tor Browser at Safest security setting when the EASE mode is enabled

[Giltyhub]

Type: code issue

HTTPS-E conflicts with NoScript in Tor Browser at Safest security setting when the EASE mode is enabled. To test this use a mixedcontent website that normally would load under EASE mode with standard security setting. i wonder if it's possible to fix this in some way.

[pipboy96]

Please give more details about this issue. How does the conflict look like?

[cschanaj]

I can reproduce this by using the "Safest" security level and setting EASE mode enabled. ~However, may I know how do you scope this down to NoScript?~ I think this could be related to the fact that only 1 extension is allowed to modify the request headers. See https://github.com/EFForg/https-everywhere/pull/14600#issuecomment-365516919

To reproduce:

1. Configure tor browser to use "Safest" security level and turn on EASE mode.
2. Visit https://mixed.badssl.com/

Expect:

The mixed content are upgraded, noticeably the tor browser shows a green padlock on the address bar.

Actual:

Mixed content warning appear.

Ref:

https://tb-manual.torproject.org/security-slider/

[pipboy96]

@cschanaj If there is mixed content, green lock never appears, even if it's rewritten, since MCB happens before WebExtensions sees the request (it can appear if all mixed content requests are blocked, for example if all of them are active).

[pipboy96]

Having different behavior with NS on and off is strange, and should be investigated since we officially support Tor Browser.

[cschanaj]

@cschanaj If there is mixed content, green lock never appears, even if it's rewritten, since MCB happens before WebExtensions sees the request (it can appear if all mixed content requests are blocked, for example if all of them are active).

IIRC, this is because we injected the upgrade-insecure-requests CSP to the response headers in EASE mode, the green padlock is shown if all requests are upgraded successfully. In such case, the requests upgrade is performed by the browser/ client, not webextensions.

P.S. I think you can reproduce the expected behavior on Firefox with EASE mode is enabled (with only HTTPSE enabled)

Possibly related #14961

[pipboy96]

High priority since this affects Tor Browser.

[ghost]

Hi,

I also experience the issue when using both HTTPS-Everywhere's EASE mode and uBlock Origin's advanced user mode: one of the extension won't be able to execute properly, the one that will fails will be randomly selected, and multiple reloads of the same page won't trigger the same behaviour.

This is typical of the CSP conflict inherent to the design of WebExtensions. Mozilla's developpers are aware of this, but the issue is low on their priority list. At first, there were no plans to correct the bug, but instead to update the documentation as it was considered normal behaviour. People reporting numerous problems made Firefox's developers review the issues and decide to fix those at a later point in time.

On a personal note, I think this issue is more problematic than it is treated as, because it breaks most privacy and security extensions, even approved and recommended by Mozilla ones.

When multiple extensions use CSP injection, each of them will simultaneously create its own version of the response header from the base one and add their own parameters, but the resulting modifications won't be merged. Instead, one version is randomly selected (no factor affects this nor allows to determine in advance which extension will "win") and sent. The conflict is silent, no notification is shown on Firefox, but I think it still is visible somewhere in Chrome, though it might have changed.

NoScript avoids the randomness by setting its listeners in a loop, thus making it always prevalent over other extensions, which is why HTTPS-Everywhere's EASE mode will constantly be overriden when in conflict with NoScript.

On another personal note, I'm hoping the Electronic Frontier Foundation or the Tor Browser's team will reach out to Firefox's developers to inform them of the severe impact this bug has on your respective software. The issue isn't as bad as it could be in Tor Browser Bundle thanks to the way NoScript sets its listeners, but that opens the door to a "listeners race" which could further aggravate the situation. I'm hoping that the HTTPS-Everywhere team will not try to work around this bug as NoScript's developer did (though it is beneficial to the Tor Browser Bundle case) but will instead ask Mozilla to raise the priority of this issue.

Here is an issue that compiles a number of real life examples of CSP conflicts in popular extensions, as well as several Bugzilla tickets and Github issues relating to the problem: sticky: unofficial: the extension csp header modification game #664 I could retrieve the numerous issues created in uBlock Origin's and uMatrix's repositories but they are mostly closed as wontfix because the real problem lies within the browser's scope.

If you need anything more (tickets, documentation, etc), please do not hesitate to ask. Lastly, thank you all for the tremendous work you put in this extension, it's incredible. You're awesome. EASE mode's implementation works wonders, and avoids most problems found in other "HTTP-to-HTTPS rewrite" extensions, I can not wait to use it again.

[cschanaj]

cc @Hainish @zoracon just in case EFF might want to implement any fix or response to this. This bug affect tor browser and if HTTPSE wins NoScript in the header rewrites, it might have certain security implications.

[pipboy96]

@cschanaj ?

[Hainish]

What's strange is that if you look at the network tab with EASE mode and the safest security setting, no HTTP requests are being made.

[Hainish]

This is not happening within Firefox with JavaScript completely disabled. I've notified Tor Browser developers of this strange behavior.