[tbb-bugs] #21323 [Applications/Tor Browser]: Activate mixed content blocking
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon May 29 09:08:39 UTC 2017
#21323: Activate mixed content blocking
-------------------------------------------------+-------------------------
Reporter: arthuredelstein | Owner: tbb-
| team
Type: defect | Status:
| needs_information
Priority: Medium | Milestone:
Component: Applications/Tor Browser | Version:
Severity: Normal | Resolution:
Keywords: TorBrowserTeam201705R, | Actual Points:
GeorgKoppen201705 |
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by gk):
Thanks for your reply, legind, this was really helpful.
Replying to [comment:18 legind]:
> Replying to [comment:17 gk]:
> > Replying to [comment:7 arthuredelstein]:
> > > Replying to [comment:2 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.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21323#comment:20>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tbb-bugs
mailing list