Opened 4 years ago

Closed 3 years ago

#9196 closed defect (fixed)

Find which rules trigger the FF23 mixed content blocker and mark them platform="mixedcontent"

Reported by: pde Owned by: lisacyao
Priority: Immediate Milestone: HTTPS-E 3.3
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Keywords:
Cc: micahlee Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by pde)

Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly label and disable those rulesets that cause problematic MCB situations.

For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.

So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.

Child Tickets

Change History (12)

comment:1 Changed 4 years ago by pde

Description: modified (diff)

comment:2 Changed 4 years ago by pde

Description: modified (diff)

comment:3 Changed 4 years ago by pde

Description: modified (diff)

comment:4 Changed 4 years ago by micahlee

After reading some of the stuff Tanvi from Mozilla has been saying, I'm starting to think that temporarily disabling the mixed content blocker is a bad idea, even as a quick fix.

As she said an email:

I don't think disabling the blocker temporarily for Firefox 23 users is a good idea. There are a few reasons for this:

  • Some domains include a mix of both HTTP and HTTPS pages. For the HTTPS pages (ex: login, purchase flow, etc) they may set a secure cookie. Their HTTP pages may have a valid cert for the HTTPS version, but they don't intended for their users to visit the HTTPS version. Hence, they may include HTTP content on these pages. When the users do visit the HTTPS version of the page, their secure cookies are protected by Mixed Content Blocker. If we turn the Mixed Content Blocker off globally, then HTTP script can steal the secure cookies.


Note that this is only an issue for Mixed Active Content. If the content is Mixed Display, the request is an HTTP request and does not include the secure cookies. The content itself (ex: an image) doesn't have access to the DOM and hence can't steal the secure cookie.


  • If a Firefox user decides to uninstall HTTPS Everywhere (for whatever reason), the setting for the Mixed Content Blocker will remain off. Uninstalling the add-on won't set the setting back to its default.

So I think we need another quick mitigation instead. I wonder if we can fix #8774 and #8776 in the next 2 weeks before we push an update, so we have 1 week left over before FF23 becomes stable so that HTTPS Everywhere users have time to upgrade our add-on before they upgrade Firefox?

I think this would be a more acceptable quick fix, though it will be far from perfect.

We still have to deal with the Mozilla MCB firing at the wrong time bug (https://bugzilla.mozilla.org/show_bug.cgi?id=878890) and the fact that many HTTPS Everywhere rules that aren't marked platform="mixedcontent" still cause mixed content problems. We should automate finding and marking these.

comment:5 Changed 4 years ago by mikeperry

The reality of the situation is that their implementation can't protect against large categories of script and content leaks either, in particular sites where the https script sources redirect to http (such scripts cannot be blocked by the nsIContentPolicy-based Mixed Content Blocker).

I think we should aim for the stopgap solution that does the least damage to sites without completely disabling the huge swaths of our ruleset database (especially rules that only cause problems with the broken nsIContentPolicy implementation), because either of those will also cause users to lose protection, via less ruleset coverage, or via uninstalling HTTPS-Everywhere

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.

As for the uninstall issue, it is possible to write an uninstall observer to reset the pref upon disable/uninstall using the addonListener service:
https://developer.mozilla.org/en-US/docs/Addons/Add-on_Manager/AddonListener

comment:6 Changed 4 years ago by micahlee

Summary: Postpone Firefox mixed content blocking from FF 23 -> 24 (with user notice & control)Find which rules trigger the FF23 mixed content blocker and mark them platform="mixedcontent"

comment:7 Changed 4 years ago by lisacyao

We've decided to aim to identify which rulesets are triggering MCB in FF23+. What I am planning to do is to pull all the target URLS from our ruleset library and use Tanvi's Mochitest to find out which ones are triggering MCB. Then, I will need to mark all the rulesets that trigger MCB with platform = "mixed_content"

I have a script that pulls <target> domains from our rulesets here: https://github.com/lisayao/HTTPS-E-Mixed-Content-Blocker-Work

Tanvi has given me some assistance and directions on how to run the Mochitest. I am in the process of cloning firefox and building it.

Micah is working on #8774 and #8776. We will resort to "Plan A" (see last paragraph above) if things don't pan out, but are hoping that will not be the case.

comment:8 Changed 4 years ago by mikeperry

Please make sure that this is fully automatable and easily reproducible. The set of rulesets broken by FF23 will be much larger than the set broken by a proper, secure implementation of MCB that doesn't use nsIContentPolicy.

This means that once we fix their mess for them, we need to go back and revisit all of these rules and turn the subset that was disabled incorrectly back on.

comment:9 Changed 4 years ago by micahlee

This is done, and the 3.3 update marked a ton of rules platform="mixedcontent". I'm keeping this ticket open for now though until we have the automated tests that we used (Firefox mochitests) in a git repository and easily reproducable. Lisa is currently working on that.

comment:10 Changed 4 years ago by titaniumbones

is there a place for users to report domains that are broken by the https-e/mixed-content combination in ff23+? In my case, sciencedirect.com (Sciverse.xml ruleset) fails to load css & js and is rendered much less usable (e.g., full article content does not load)

comment:11 in reply to:  10 Changed 4 years ago by micahlee

Replying to titaniumbones:

is there a place for users to report domains that are broken by the https-e/mixed-content combination in ff23+? In my case, sciencedirect.com (Sciverse.xml ruleset) fails to load css & js and is rendered much less usable (e.g., full article content does not load)

I think you should report them like any other HTTPS Everywhere bug. You can open a new ticket here, or send an email to the https-everywhere-rules listserve. I just opened a new ticket for sciencedirect.com: #9784

comment:12 Changed 3 years ago by jsha

Resolution: fixed
Status: newclosed

14 months in, this is mostly done. Any remaining mixed-content problems will be dealt with as one-offs.

Note: See TracTickets for help on using tickets.