[HTTPS-Everywhere] Help needed: Disabling 3,080 rulesets

[Mike Perry]

Jacob Hoffman-Andrews:
> 
> On 02/11/2015 12:04 PM, Mike Perry wrote:
> > Out of curiosity, did you also check for rules that were damaged by
> > https://bugzilla.mozilla.org/show_bug.cgi?id=878890?
> No. The tool I'm using doesn't yet test for mixed content. Micah's
> ruleset tests do, but I haven't successfully run them in a while. My
> general feeling is that most rulesets with mixed content have been found
> by users and fixed, although that may be much less true for the rules
> that exist only in the development branch.

So in the meantime, is it your plan to remove all of the currently
tagged platform="mixedcontent" rules caused by Bug 878890? In Tor
Browser, we would rather have those rules enabled, which happens if
either 'security.mixed_content.block_active_content' or
'extensions.https_everywhere.enable_mixed_rulesets' are set.

> > You should be able to test that by setting
> > security.mixed_content.block_active_content to false when testing
> > rulesets, because the mixed content blocker blocks elements from https
> > sites that get redirected by HTTPS-Everywhere into https. In the past,
> > rules that tripped over that bug have been tagged with
> > platform="mixedcontent". I ask because in Tor Browser, we've been also
> > setting security.mixed_content.block_active_content to false, to allow
> > HTTPS-Everywhere to enable rules that were broken specifically by that
> > bug. 
> That's good to know, I didn't realize that Tor Browser has a different
> mixed content setting. Doesn't that put users at greater risk, on sites
> that aren't fixed up by HTTPS Everywhere?

TL;DR: Due to Bug 878890, we were forced to choose between HTTPS
coverage and a janky half-working implementation of Mixed Content
Blocking that ultimately caused reduced HTTPS coverage. We felt the
increased HTTPS coverage provided better protection against remote code
execution than Mixed Content Blocking does. So we disabled Mixed Content
Blocking to get greater HTTPS coverage.


Our thinking here was that with enough coverage from HTTPS-Everywhere,
the "Medium" setting on our Security Slider can disable *all* non-HTTPS
Javascript, including any HTTPS or non-HTTPS javascript sourced from a
non-HTTPS url bar. So in this setting, we block a superset of the
Javascript that mixed content blocking blocks, and in fact should load
no unauthenticated JS at all.

With a large set of HTTPS-Everywhere rules, it was my hope that this
could be done without a huge impact on usability.

This seems to me to be a better way of dealing with the risk of remote
code execution from content injection (either at the exit node, or by
Quantum Insert), but obviously it isn't so usable if a great many
HTTPS-Everywhere rules get disabled due to
https://bugzilla.mozilla.org/show_bug.cgi?id=878890.

In my view, mixed content blocking mostly protects broken/misconfigured
websites from cross-site attacks from junk they happen to source
accidentally, and is less about protecting users from remote code
execution (because it doesn't actually block anything hostile on an http
origin). Hence, we made the decision in favor of protecting against
RCE.

It seems that the perpetually broken mixed content blocking protection
in Firefox (and I think Chrome too, FWIW, as they both standardized on
braindamaged behavior wrt redirects and addon+HSTS upgrades) is making
that less feasible, especially if you're being forced to abandon
thousands/tens of thousands of HTTPS rules due to that bug :/.



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <https://lists.eff.org/pipermail/https-everywhere/attachments/20150211/13236b42/attachment.sig>