[tbb-bugs] #21323 [Applications/Tor Browser]: Activate mixed content blocking

[Tor Bug Tracker & Wiki]

#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 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.

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

 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

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

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21323#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online