[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-

 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-

 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