Opened 7 years ago

Closed 7 years ago

Last modified 5 years ago

#8774 closed defect (fixed)

Disable mixed content rulesets on FF 23+

Reported by: pde Owned by: micahlee
Priority: Very High Milestone: HTTPS-E 4.0dev8
Component: HTTPS Everywhere/EFF-HTTPS Everywhere Version:
Severity: Normal Keywords:
Cc: sid@…, tanvi@…, micahlee, brian@…, mamacdon@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Mixed content blocking has landed in FF 23 nightly.

Child Tickets

#8664closedpdeFirefox 23 blocks loading of HTTPS/HTTP mixed content, breaking nytimes.comHTTPS Everywhere/EFF-HTTPS Everywhere
#8674closedpdeInstalling HTTPS Everywhere + security.mixed_content.block_active_content breaks Youtube.comHTTPS Everywhere/EFF-HTTPS Everywhere
#8776closedmicahleeChanges to default ruleset state need to work even if the rule was previously presentHTTPS Everywhere/EFF-HTTPS Everywhere

Change History (13)

comment:1 Changed 7 years ago by pde

I've committed the first part of a solution to this, but this isn't a real fix until we have a way to fix or work around the fact that those rulesets won't be disabled unless their names are also changed.

comment:2 Changed 7 years ago by pde

Cc: sid@… tanvi@… micahlee added
Priority: normalcritical

CCing Micah, Lisa and some folks over at Mozilla (Tanvi and Sid) who landed the mixed content blocking feature. This is either the first ticket that Lisa should look at for her GSOC project, or something we should clear out of the way for her to start on some code to detect blocked mixed content situations. If we close this, we should be about as sane on Firefox 23+ as we are on Chrome.

Which is not to say "great", but a lot better than the chaos that would ensue otherwise.

After that our goal will be to either disable mixed content blocking if the only reason mixed content happened was because of HTTPS Everywhere, or to do a much better job of identifying and disabling all of the rulesets that cause it to happen.

comment:3 Changed 7 years ago by pde

Milestone: HTTPS-E 4.0dev7HTTPS-E 4.0dev8

tanvi and I have been chatting about this in #security on For everyone who isn't there:

<tanvi> pde: ping
<tanvi> pde: thanks for cc'ing me on your mixed content bug. you mentioned that you might try disabling mixed content blocker. i don't think your addon can change the pref without causing a warning/alert when submitting to AMO for review
<tanvi> that is a privileged pref that addons can't change
<pde> tanvi: what we'd want would be a way to disable it in specific contexts
<pde> we wouldn't want blanket disablement, since I think that would decrease user security overall
<pde> and I guess I'm not committed to trying to do things that way, it's just one of the options
<tanvi> hmm; not sure if that coudl be accomplished
<tanvi> i suppose you coudl include javascript in the addon that looks for the shield after https everywhere rewrites a url and selects "Disable Protection on this page"
<pde> exactly the sort of hackery I'm afraid of
<tanvi> we have a mochitest that you could use to find broken sites
<pde> alternatively we could write the same javascript (or use mochitest) and try to disable our rewrites for those sites
<tanvi> not sure if it will work with the addon; but if you take alexa top X sites and run them through your rewrite rules
<tanvi> you can then take the https urls that you get and put them through the mochitest
<pde> we can also do it with opt-in user pingbacks
<tanvi> the results of the mochitest will tell you whether or not Mixed Active Content was detected on the page
<pde> oh I see
<tanvi> once you know which of yoru rewrite rules result in pages with Mixed Active Content, you can disable those rewrite rules
<pde> the hard part of that is that sometimes Mixed Active Content will happen in really obscure parts of sites, only for logged in users, etc
<tanvi> pde - yeah, that is true
<pde> so I think our best chance will be to opt-in instrument our users in the wild and see where it's happening
<tanvi> we tested the top 1000 alexa sites for mixed content, and found 77 with mixed active content. but we only tested the homepage and we didnt log in
<pde> we have already found quite a few via manual reporting from our chrome userbase
<pde> but I think we currently just offer our chrome users a much worse experience than our firefox users
<tanvi> even before Firefox 23, you can listen for certain nsWebProgressListener flags. specifically STATE_LOADED_MIXED_ACTIVE_CONTENT
<tanvi> that will tell you if the mixed content blocker will be invoked for a website.
<tanvi> prior to FF23
<tanvi> in FF23 (when it is blocked by default) you woudl look for STATE_BLOCKED_MIXED_ACTIVE_CONTENT
<pde> oh that's super helpful

comment:4 Changed 7 years ago by briansmith

Cc: brian@… added

pde: One of the next steps for the mixed content blocker for Firefox should be to prevent addons from introducing mixed (active) content into a page and/or disabling the mixed content blocking on any page. (See Mozilla bugs 875606 and bug 875607.) Mixed active content is a serious security concern for the affected site and I don't think that users would expect addons--especially important security-enhancing tools like HTTPS Everywhere--to add security vulnerabilities to any site. It is somewhat of a judgement call as to whether mixed content is worse than less/no HTTPS. As far as I'm concerned, the best thing for HTTPS Everywhere in Firefox to do--even long term--is to simply disable all the rules that cause mixed content situations. And, I think that Firefox should (eventually) make things like "disable mixed content blocking if the only reason mixed content happened was because of addon" impossible in any case.

comment:5 Changed 7 years ago by mikeperry

For Tor's use case, the current mixed content blocking in Firefox offers no significant benefit as-is. The "active vs passive content" blocking distinction does not reflect the realities of the capabilities of cookie theft adversaries, and the use of nsIContentPolicy makes the security properties subject to the irregular behaviors and incomplete coverage of that API.

If Tor Browser were to head in the partial content blocking direction, it would be to disable *all* Javascript from non-https schemes regardless of the sourcing scheme, and provide our own doorhanger UI to enable scripts for that first party url bar domain if the user desired. (NoScript is somewhat capable of doing this for us already, but the UX is abysmal and not in any way related to the first party url.)

Under this model, we would want to leave these HTTPS-Everywhere mixed content rules enabled, and we would simply entirely disable the native insecure partial mixed content blocking in Tor Browser. I imagine vanilla Firefox users who use both HTTPS-Everywhere and NoScript would be in favor of an option to keep these rules enabled for this "no javascript over http" usage patten, as well.

In fact, since HTTPS-Everywhere already implements an http-on-modify-request observer, we could pretty much disable whatever Firefox does and re-implement it easier, cleaner, and more securely from our own observer. Then we could provide the user with multiple options: Full, strict mixed content blocking; https-only Javascript loading; and Firefox-style insecure partial blocking and rule neutering.

comment:6 Changed 7 years ago by mamacdon

Cc: mamacdon@… added

comment:7 Changed 7 years ago by micahlee

Owner: changed from pde to micahlee
Status: newassigned

Ok, so me and Lisa have decided to try to cram to fix this bug and also #8776 in the next two weeks. We also want to try to mark far more rules that cause mixed content bugs as platform="mixedcontent".

A quick scan of the current stable rules shows that:

There are 3039 total stable rules
There are 323 rules that are default_off
2 of the default_off rules are marked mixed_content
16 of the other 2716 rules are are marked mixed_content

Yesterday me, Lisa, and Dan took a random sampling of 30 rules (a small set, I know, but we did it manually) and loaded the homepages of those rules in FF23. Ignoring the ones that were default_off (and the 2 that timed out because they were down) we found that:

20% triggered the MCB
80% worked fine

Assuming that this is statistically accurate, we probably need to mark about 527 more rules as mixedcontent.

mikeperry, I see your comment in #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.

I agree that there all these options kinda suck. I think disabling 20% of the rules might be worth it over disabling new security features that ship with Firefox.

We also decided that disabling the MCB is still on the table if we run into trouble. If it turns out that we can't actually do all of this in time, or if it turns out that we have to disable significantly more rules than we though then we have code that's mostly ready (needs to work out some UI issues) to turn temporarily disable the MCB in Lisa's github repo:

I'm also updating #9196 from turning off the MCB to marking rules as mixed content.

comment:8 Changed 7 years ago by micahlee

FYI, I've made a lot of progress on #8776 today, including a patch if anyone wants to test it.

If I can finish it soon, then we just need to finish #9196 to mark rules as mixedcontent and release an update, and the crisis will be somewhat averted.

comment:9 Changed 7 years ago by mikeperry

Please make sure it is easy to re-enable these rules. I am going to disable MCB in the 24-ESR based TBB until I have time to fix the MCB implementation and its bugs (including the nsIContentPolicy security issues not related to HTTPS-Everywhere, of which there are several).

Also note that in the meantime, if we leave MCB enabled for stock Firefox HTTPS-Everywhere users, ruleset authors will try to write rules that fail for opaque and hard-to-diagnose reasons (due to nsIContentPolicy issues). This will undoubtedly discourage that volunteer community, and may lead new volunteers to conclude our software is simply broken.

I really think we're letting Mozilla force us to shoot off our own foot with this MCB stuff (or at least outsource their dev workload on MCB to us), and it seems to be entirely because they've discovered that it matters more to us that MCB is done correctly and securely than it matters to them :/.

comment:10 Changed 7 years ago by Tanvi

HTTPS Everywhere aside, the Mixed Content Blocker does not properly handle redirects. This is a known issue and it is important for us to fix this. We first talked to Peter about the compatibility issues in April. And we also communicated this as soon as the feature was turned on in nightly ( - see Remaining Edge Cases and Appendix sections). However, as described, we didn't want the edge cases to delay the release of the MCB. We believe that 95% protection is better than no protection for Firefox users.

The Mixed Content Blocker is an important security feature with many moving parts. We are doing the best we can with the time we have, keeping in mind our goal to protect users sooner than later. Fixing the redirect issue and bug 878890 is on my radar, but there are more pressing issues that we have to attend to first, or else we risk the feature being disabled for all Firefox users. When prioritizing tasks, we have to consider security for the majority of Firefox users and hence we have to complete a few other tasks before we get to bug 878890. If the EFF can help fix bug 878890, we are happy to have the extra help. Otherwise, we will get to it but it will take some time.

HTTPS Everywhere had the same issues with Chrome. You had to identify and disable rulesets with Mixed Content. For Firefox, we are in a similar situation except that this is a temporary solution (rather than permanent). I've been working closely with Lisa to help her identify which rulesets cause mixed content.

comment:11 Changed 7 years ago by micahlee

Resolution: fixed
Status: assignedclosed

comment:12 Changed 5 years ago by anneuffe

Cc: anneuffe@… added
Parent ID: #6975

comment:13 Changed 5 years ago by anneuffe

Cc: anneuffe@… removed
Severity: Normal
Note: See TracTickets for help on using tickets.