Activate mixed content blocking
I'm informed that HTTPS-Everywhere has likely disabled any rules that break with mixed content blocking for active content, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c20. So I think we should activate MCB (set "security.mixed_content.block_active_content" to true). It seems dangerous to have it disabled, and Firefox's default value is true as well.
Activity
Here's my patch for review: https://github.com/arthuredelstein/tor-browser/commit/21323
Trac:
Keywords: N/A deleted, TorBrowserTeam201701R added
Status: new to needs_review
Replying to arthuredelstein:
I'm informed that HTTPS-Everywhere has likely disabled any rules that break with mixed content blocking for active content, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c20.
What does "likely" mean? And where can I find out more about that change?
Trac:
Status: needs_review to needs_informationWe test rulesets with the default settings in browsers which blocks active mixed content, but note the comment here: https://www.eff.org/https-everywhere/rulesets#mixed-content-blocking-mcb
Some rulesets may trigger active mixed content (i.e. scripts loaded over HTTP instead of HTTPS). This type of mixed content is blocked in both Chrome and Firefox, before HTTPS Everywhere has a chance to rewrite the URLs to an HTTPS version. This generally breaks the site. However, the Tor Browser doesn't block mixed content, in order to allow HTTPS Everywhere to try and rewrite the URLs to an HTTPS version.
To enable a rule only on platforms that allow mixed content (currently only the Tor Browser), you can add a
platform="mixedcontent"attribute to the ruleset element.It appears that for sites lacking a matching ruleset with the
platform="mixedcontent"directive set, some Active Mixed Content is still being allowed in TB. Here's a simple test site I found: https://www.bennish.net/mixed-content.htmlDupe of #13033 (moved)?
Replying to cypherpunks:
Dupe of #13033 (moved)?
Not a duplicate. This ticket is about flipping a pref. #13033 (moved) is about patching the implementation of the pref.
Replying to gk:
Replying to arthuredelstein:
I'm informed that HTTPS-Everywhere has likely disabled any rules that break with mixed content blocking for active content, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c20.
What does "likely" mean? And where can I find out more about that change?
I think I misspoke here. But I've done some further investigation. I searched the HTTPS Everywhere codebase and found 1258/22080 rulesets (5%) contain
platform="mixedcontent"attribute. These run only if active mixed content is allowed, as in Tor Browser.I had further discussions with legind and I think he makes a pretty good argument that we should be blocking active mixed content nonetheless:
I think for the sites that will have their rulesets disabled by flipping the "mixedcontent" bit, their security will be downgraded a little. But their security is already compromised by the fact that active mixed content is being loaded on the page, which seems a huge downside. And for sites that aren't included in HTTPS Everywhere, ensuring active mixed content is not loaded on the page is a big win
Additionally, I think Tor Browser needs to be especially careful about this because of the potential for script injection by exit nodes.
I created a demo page to test loading of mixed content in Tor Browser: https://arthuredelstein.github.io/tordemos/mixed-content.html Results are as follows:
- Low Security: Script is loaded and run over http.
- Medium Security: Script is not loaded (http scripts are blocked by NoScript).
- High Security: Script is not loaded (all scripts are blocked by NoScript).
When using High Security and visiting an https site, I often run into a page that is broken without scripts. In that case I will sometimes click on the NoScript button and select "Temporarily allow all this page", because it seems relatively safe on an https site. But note in this demo, doing that results in a script being loaded over http and running.
So at the very least I think we should be blocking mixed active content at High Security, and my feeling is we should probably blocked mixed active content at all security levels.
Potentially, we could also patch HTTPS Everywhere to add a pref that enables the
platform="mixedcontent"rulesets even when active mixed content is being blocked. We could enable this pref at Medium and High Security for maximum protection.Trac:
Status: needs_information to needs_reviewReplying to arthuredelstein:
Potentially, we could also patch HTTPS Everywhere to add a pref that enables the
platform="mixedcontent"rulesets even when active mixed content is being blocked. We could enable this pref at Medium and High Security for maximum protection.legind just told me this already exists: "extensions.https_everywhere.enable_mixed_rulesets".
Trac:
Username: tokotoko
Cc: N/A to fdsfgs@krutt.org-
#21831 (moved) is a duplicate of this one. Note there that it is suggested that mixed content blocking at least on the "High" setting should be disabled (as mentioned in comment:7) but probably on all levels, though.
There is the additional "if we can't enable it by default then let the user enable it as there is a button for it" request which I'll open a ticket for in case we finally decide to not activate the mixed content blocking by default.
Trac:
Cc: fdsfgs@krutt.org to fdsfgs@krutt.org, jonathanfemideer Note that in the transition to the WebExtensions version of HTTPS Everywhere, we will no longer have access to browser prefs. See: https://wiki.mozilla.org/WebExtensions/FAQ#Will_I_have_access_to_about:config_or_the_preferences.3F
Because of this we won't be able to tell from prefs whether mixed content blocking is enabled or not, and setting the above-mentioned pref will be ineffective.
One possibility is setting a localStorage variable enable_mixed_rulesets and setting that to the desired value within the HTTPS Everywhere extension scope at browser startup.
-
Replying to arthuredelstein:
Replying to gk:
Replying to arthuredelstein:
I'm informed that HTTPS-Everywhere has likely disabled any rules that break with mixed content blocking for active content, as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c20.
What does "likely" mean? And where can I find out more about that change?
I think I misspoke here. But I've done some further investigation. I searched the HTTPS Everywhere codebase and found 1258/22080 rulesets (5%) contain
platform="mixedcontent"attribute. These run only if active mixed content is allowed, as in Tor Browser.I had further discussions with legind and I think he makes a pretty good argument that we should be blocking active mixed content nonetheless:
I think for the sites that will have their rulesets disabled by flipping the "mixedcontent" bit, their security will be downgraded a little. But their security is already compromised by the fact that active mixed content is being loaded on the page, which seems a huge downside.
I don't understand that: those 5-6% of sites not being redirected to HTTPS because the Mixed Content Blocker kicks in means that users are staying effectively on HTTP pages with all the side effects. Not sure what "downgraded a little" means in this context. But why is their security already compromised with HTTPS-Everywhere redirecting everything to HTTPS? The problem here is that the MCB is interfering too early and basically denying the load not knowing that it would not get delivered as a HTTP request but an HTTPS one due to HTTPS-Everywhere rewriting it. Thus, there is no security compromise for those 5-6% of sites in Tor Browser as there is no active mixed content loaded in the first place.
And for sites that aren't included in HTTPS Everywhere, ensuring active mixed content is not loaded on the page is a big win
In what regard? JS loaded over HTTPS can easily redirect to JS loaded over HTTP and Firefox will happily execute it as the MCB does not kick in in that case. And that's just one of the problems.
We had this discussion already 4 years ago, see #9196 (moved). So my question would be: What has changed meanwhile so that we should revisit our decision which Mike summarized in comment:5:ticket:9196:
Given that our only choices seem to be "disable a ton more rules than we should", "seriously degrade the user experience of HTTPS-Everywhere users", and "disable mixed content until it can be done right", I think the least invasive choice is the third one.FWIW: I think what we (or better Mozilla) really should do is fixing the underlying issue (a.k.a https://bugzilla.mozilla.org/show_bug.cgi?id=878890 or #13033 (moved)) which would avoid the need for us to pick the least bad option out of suboptimal ones.
Trac:
Cc: fdsfgs@krutt.org, jonathanfemideer to fdsfgs@krutt.org, jonathanfemideer, legind
Status: needs_review to needs_information Replying to gk:
Replying to arthuredelstein:
Replying to gk:
I had further discussions with legind and I think he makes a pretty good argument that we should be blocking active mixed content nonetheless:
I think for the sites that will have their rulesets disabled by flipping the "mixedcontent" bit, their security will be downgraded a little. But their security is already compromised by the fact that active mixed content is being loaded on the page, which seems a huge downside.
I don't understand that: those 5-6% of sites not being redirected to HTTPS because the Mixed Content Blocker kicks in means that users are staying effectively on HTTP pages with all the side effects. Not sure what "downgraded a little" means in this context. But why is their security already compromised with HTTPS-Everywhere redirecting everything to HTTPS? The problem here is that the MCB is interfering too early and basically denying the load not knowing that it would not get delivered as a HTTP request but an HTTPS one due to HTTPS-Everywhere rewriting it. Thus, there is no security compromise for those 5-6% of sites in Tor Browser as there is no active mixed content loaded in the first place.
The problem is that HTTPS Everywhere doesn't redirect everything to HTTPS for mixed-content rulesets. The attribute
platform="mixedcontent"means that for browsers that do block mixed content, insecure content will be blocked on the HTTPS endpoint and result in disruption of the user experience in some substantive way. Conversely and necessarily, for browsers not blocking mixed content, an HTTPS site will be loading resources insecurely. The purpose of that flag is to ensure that the user experience is not disrupted in either case, allowing users to get at the content they need either way. In the case of mixed-content-blocking browsers, allowing them to access the HTTP endpoint. In the case of non-mixed-content-blocking browsers, having insecure content loaded on the HTTPS endpoint.This is what I mean by downgraded a little. In this context, it that the 5% of sites with
platform="mixedcontent"HTTPS Everywhere rulesets in mixed-content-blocking browsers will be loading an HTTP page with HTTP includes, rather than an HTTPS page with HTTP includes. In either case, it's insecure - any 3rd party script can completely rewrite the contents of a page. It just requires a little more work than directly rewriting an HTTP page.And for sites that aren't included in HTTPS Everywhere, ensuring active mixed content is not loaded on the page is a big win
In what regard? JS loaded over HTTPS can easily redirect to JS loaded over HTTP and Firefox will happily execute it as the MCB does not kick in in that case. And that's just one of the problems.
This is just not the case. If active mixed content is blocked, even if an HTTPS resource redirects to HTTP, it will not be executed.
The coverage of HTTPS Everywhere is, despite the name, far from 100%. This is more true now, with the availability to deploy HTTPS in an automated fashion and for free, than before. For those sites with HTTPS but without coverage, we're opening users up to increased risk by continuing to allow mixed content.
We had this discussion already 4 years ago, see #9196 (moved). So my question would be: What has changed meanwhile so that we should revisit our decision which Mike summarized in comment:5:ticket:9196: {{{ Given that our only choices seem to be "disable a ton more rules than we should", "seriously degrade the user experience of HTTPS-Everywhere users", and "disable mixed content until it can be done right", I think the least invasive choice is the third one. }}}
When the browsers first turned on mixed content blocking, anyone using HTTPS Everywhere visiting a site with mixed content not only had their content blocked, but also had no recourse to downgrade their connection to HTTP in order to access content. This effectively made us a censorship tool for improperly configured sites. Lots of sites were affected at the time, and thus the trade-off of disabling mixed content in order to make that content available was a reasonable one at the time. Many sites have fixed this problem since this decision was made, and (at least for the largest ones) our own rulesets have changed to reflect this.
Additionally, many rulesets marked as
platform="mixedcontent"have since removed their HTTPS endpoints altogether, deciding it wasn't worth it to provide HTTPS if they couldn't do it right. In a random sampling of 10 of such rulesets, half of them were not accessible at all over HTTPS. This means that they're not accessible at all over Tor Browser. See https://github.com/EFForg/https-everywhere/issues/9971#issuecomment-304158762FWIW: I think what we (or better Mozilla) really should do is fixing the underlying issue (a.k.a https://bugzilla.mozilla.org/show_bug.cgi?id=878890 or #13033 (moved)) which would avoid the need for us to pick the least bad option out of suboptimal ones.
This is another issue entirely, partially mitigated by
upgrade-insecure-requests, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests.Replying to legind:
In what regard? JS loaded over HTTPS can easily redirect to JS loaded over HTTP and Firefox will happily execute it as the MCB does not kick in in that case. And that's just one of the problems.
This is just not the case. If active mixed content is blocked, even if an HTTPS resource redirects to HTTP, it will not be executed.
Load https://www.inputoutput.io/non-wp/amcb-test.html and look at the web console and network pane in the debugger to check this.