Opened 3 years ago

Closed 2 years ago

Last modified 18 months ago

#21323 closed defect (fixed)

Activate mixed content blocking

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: TorBrowserTeam201705R, GeorgKoppen201705
Cc: fdsfgs@…, jonathanfemideer, legind Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (24)

comment:1 Changed 3 years ago by arthuredelstein

Keywords: TorBrowserTeam201701R added
Status: newneeds_review

comment:2 in reply to:  description ; Changed 3 years ago by gk

Status: needs_reviewneeds_information

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?

comment:3 Changed 3 years ago by legind

We 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.

comment:4 Changed 3 years ago by legind

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.html

Last edited 3 years ago by legind (previous) (diff)

comment:5 Changed 3 years ago by cypherpunks

Dupe of #13033?

comment:6 in reply to:  5 Changed 3 years ago by arthuredelstein

Replying to cypherpunks:

Dupe of #13033?

Not a duplicate. This ticket is about flipping a pref. #13033 is about patching the implementation of the pref.

comment:7 in reply to:  2 ; Changed 3 years ago by arthuredelstein

Status: needs_informationneeds_review

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.

comment:8 in reply to:  7 Changed 3 years ago by arthuredelstein

Replying 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".

comment:9 Changed 3 years ago by gk

Keywords: TorBrowserTeam201702R added; TorBrowserTeam201701R removed

Moving review tickets.

comment:10 Changed 2 years ago by gk

Keywords: TorBrowserTeam201703R added; TorBrowserTeam201702R removed

No February anymore.

comment:11 Changed 2 years ago by tokotoko

Cc: fdsfgs@… added

comment:12 Changed 2 years ago by gk

Cc: jonathanfemideer added

#21831 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.

comment:13 Changed 2 years ago by gk

Keywords: TorBrowserTeam201704R added; TorBrowserTeam201703R removed

Moving review tickets to April.

comment:14 Changed 2 years ago by gk

Keywords: TorBrowserTeam201705R added; TorBrowserTeam201704R removed

Moving review tickets to May.

comment:15 Changed 2 years ago by legind

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.

comment:16 Changed 2 years ago by gk

Keywords: GeorgKoppen201705 added

comment:17 in reply to:  7 ; Changed 2 years ago by gk

Cc: legind added
Status: needs_reviewneeds_information

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. 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) which would avoid the need for us to pick the least bad option out of suboptimal ones.

comment:18 in reply to:  17 ; Changed 2 years ago by legind

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. 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-304158762

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) 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.

comment:19 in reply to:  18 Changed 2 years ago by legind

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.

comment:20 in reply to:  18 ; Changed 2 years ago by gk

Thanks for your reply, legind, this was really helpful.

Replying to legind:

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.

Well, sure, if websites governed by mixedcontent rules include third party resources (over http) that do not have a respective HTTPS-Everywhere rule then those are loaded over HTTP and you don't get much benefit from the mixedcontent rule. I am not sure how prevalent this kind of pattern is but my assumption was that a lot of mixedcontent rules don't follow that one.

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.

Oh, this got fixed in the meantime then, good. I was a bit confused as the related bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=878890 and https://bugzilla.mozilla.org/show_bug.cgi?id=1006881 are still open. But https://bugzilla.mozilla.org/show_bug.cgi?id=418354 solves the problem and thus Firefox users since 36 (or 38) are not effected anymore by it.

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. 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-304158762

Thanks, that's good to know.

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) 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.

No, it is not. See: https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c3. If the content policy (which Mixed Content Blocking (MCB) relies on) would have been called after all the redirects would have taken place we would not have this discussion now. :) But as I said above, while Mozilla did not fix the underlying problem they solved it differently for the MCB case.

Alright, after going over all the arguments I think it is okay for us to activate mixed content blocking. I won't do that by setting the pref to true as Arthur did but just by removing that entry in our 000-tor-browser.js, which means we are using the default Firefox provides (which is enabling the mixed content blocker) from now on.

comment:21 in reply to:  20 Changed 2 years ago by gk

Resolution: fixed
Status: needs_informationclosed

Replying to gk:

Replying to legind:

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.

No, it is not. See: https://bugzilla.mozilla.org/show_bug.cgi?id=878890#c3. If the content policy (which Mixed Content Blocking (MCB) relies on) would have been called after all the redirects would have taken place we would not have this discussion now. :) But as I said above, while Mozilla did not fix the underlying problem they solved it differently for the MCB case.

Actually, I have not checked whether it can still be the case that resources loaded over HTTP that would have been rewritten by an HTTPS-Everywhere rule (but are not due to MCB) would still be blocked by MCB before that could happen. If so, then the bug is still open for a good reason (and our #13033) as well. What I just meant was that redirects are taken into account now, so that the HTTPS -> HTTP downgrade issue is not a problem anymore.

Alright, after going over all the arguments I think it is okay for us to activate mixed content blocking. I won't do that by setting the pref to true as Arthur did but just by removing that entry in our 000-tor-browser.js, which means we are using the default Firefox provides (which is enabling the mixed content blocker) from now on.

This is done with commit c1a5e1abf6ee05b0b1d3b1462b3c9e1c180b153e and 29b34b444229fd09fcf7741a206230385e843fde on tor-browser-52.1.0esr-7.0-2 and tor-browser-52.1.1esr-7.0-1.

comment:22 Changed 2 years ago by cypherpunks

@gk There's also a related ticket (probably duplicate of #13033 ?): "Should not generate mixed-content warnings if rewriting all http to https" #3777

Last edited 2 years ago by cypherpunks (previous) (diff)

comment:23 Changed 21 months ago by cypherpunks

Maybe it's time now to ask Mozilla to fix the underlying bug now that they moved to WebExtension? https://bugzilla.mozilla.org/show_bug.cgi?id=878890

comment:24 Changed 18 months ago by cypherpunks

Mozilla implemented in FF60 Mixed Content upgrading for static content https://bugzilla.mozilla.org/show_bug.cgi?id=1435733 Doesn't fix the underlying issue with HTTPS-E but may be interesting to flip for more security.

Note: See TracTickets for help on using tickets.