838395 - Pages with HSTS subresources, referenced using http:// URLs, are displayed as having mixed content even though no non-HTTPS loads occur

Status: NEW

(Core :: DOM: Security, defect, P3)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

<tanvi> https://blog.mozilla.org/nnethercote/2013/01/23/memshrink-progress-week-83-84/awsy-2/ url

<dholbert> ah! there is <script src="http://blog.mozilla.org/nnethercote/?live-comment-preview.js in the page source

<bsmith> The problem is that content policy's shouldLoad is called before we create the channel and then mixed content blocker content policy classifies the load as mixed content but, later, we do an internal redirect to convert the reques from http:// to https:// because of the Strict-Transport-Security header. So, basically, the nsIContentPolicy-based mixed content blocker is incompatible with strict transport security.

Either we need to wallpaper over this or we need to fix bug 815329, soon.

Comment 1

[Potch [:potch]]

This seems like a great thing to fix. The web is fault-tolerant by its very nature, and given that the final result is *actually* a secure connection thanks to HSTS, it shouldn't be blocked.

Additionally, any blocked request had better be logged as such in a user-visible place, or we are looking at a developer relations nightmare.

Comment 2

[Ian Melven :imelven]

(In reply to Potch [:potch] from comment #1)
>
> Additionally, any blocked request had better be logged as such in a
> user-visible place, or we are looking at a developer relations nightmare.

see Bug 837351 - When mixed content is blocked, show the blocked URL in the Error Console and WebConsole

Comment 3

[Gervase Markham [:gerv]]

If we are about making the web better for everyone, then indicating that this is a risky situation is still a good idea. It's just not risky _for_Firefox_users_. That might suggest that we display it in primary UI as safe, but in developer UI as problematic.

Gerv

Comment 4

[Tanvi Vyas[:tanvi]]

I don't think developers should rely on HSTS saving their websites from mixed content.

Assume the HSTS website isn't on the preload list.  If this is the first time the user has loaded content from the site, the content will be loaded over HTTP since the browser has not yet received and HSTS header from the website and doesn't know to convert it to HTTPS.

For browser that do not have HSTS implemented (ex: Internet Explorer), the website will have mixed content.  If the content is Active content (scripts, stylesheets, frames, etc) than the load will be blocked on IE and IE will present a warning to the user.

Comment 5

[Tanvi Vyas[:tanvi]]

For the reasons stated above (and also described in the mixed content blocker blog post - https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/ - I think this should be marked Won't Fix.

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The purpose of this proposed feature isn't to enhance the the security of the sites that would benefit from it. Rather, the purpose of the feature is to limit the negative compatibility impact of the mixed content blocker.

Do you think that this is actually a harmful feature, or are you just concerned that it isn't worth the resources to implement it? I ask because this would get fixed automatically as a side effect of fixing bug 776278, if we fix that bug.

Comment 7

[Ryan Sleevi]

Just a drive-by commentary: This is being discussed as a Chromium bug as well (marginally, https://code.google.com/p/chromium/issues/detail?id=122548 , which related to our extensions - but is due to the same implementation details as our HSTS implementation).

From our discussions within the Chromium team and with our security team, which are basically what Tanvi outlined - our view is surfacing these errors as "mixed content" even when loaded over an HSTS-domain is a reasonable behaviour.

In the end though, it's all UI, so we may of course choose to disagree. But it does seem "nice" to surface it consistently.

Comment 8

[Daniel Kahn Gillmor]

I can marginally see the argument about providing the "mixed content" UI for off-origin content that happened to be protected by HSTS.  I'm not actually convinced, though, because it means that the security UI is not actually describing the security features of the current connection.  I think that violates one of the baseline assumptions that users have about what their browser is showing them.

For sites where the only "mixed content" is actually same-origin content (mistakenly referred to via http:// instead of https:// for whatever reason), and where that content is protected by an HSTS pin from loading the origin page, the argument to show the "mixed content" UI is even weaker, though.

And the mixed-content blocker (both active and passive) should be applied to same-origin content *after* the HSTS rewriting happens, not before.

Gervase's suggestion (comment 3) of showing "safe" in the primary UI and problematic in the developer-specific UI seems like a good one to me.

Comment 9

[David Bruant]

(In reply to Gervase Markham [:gerv] from comment #3)
> If we are about making the web better for everyone, then indicating that
> this is a risky situation is still a good idea. It's just not risky
> _for_Firefox_users_. That might suggest that we display it in primary UI as
> safe, but in developer UI as problematic.
Agreed. This is a developer-only issue, but it is an issue that is worth reporting to devtools as it may just be an omission by developers. It will become an issue if the targeted website stops HSTS for whatever reason.
It may be a good occasion to introduce people to "//" relative URLs ;-)

Comment 10

[Frederik Braun [:freddy]]

Could we change the bug title? The issue also appears on wesbites that are not HSTS but do include cached-as-HSTS-enabled resources as a http:// URL.

Comment 11

[Henri Sivonen (:hsivonen)]

This bug makes it substantially harder for sites that have a large body of legacy content to migrate to https. That's bad. www.w3.org is an example of such a site: http://lists.w3.org/Archives/Public/www-tag/2014Nov/0033.html

I think the primary UI should not complain about mixed content when the actual loads are actually upgraded by HSTS. Whining in the developer tools makes sense, though.

Comment 12

[Tanvi Vyas[:tanvi]]

Doing HSTS checks before Mixed Content Blocker checks is dependent on https://bugzilla.mozilla.org/show_bug.cgi?id=1006881.

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

Most likely it will still take some time till Bug 1006881 is resolved and content policies (in particular mixed content blocker) is not evaluated before HSTS. I think we could already make a small step towards better usability for pinned domains and except those loads from mixed content blocking. We are using a very similar approach for CSPs 'upgrade-insecure-requests' directive [1]. At this point within mixed-content-blocker we know that the request will be upgraded to https before it hits the network.

Now, if we could expose some kind of interface so mixed-content-blocker knows about pinned domains, then we could just log a message to the console that HSTS will upgrade that request and exempt it from blocking.

I chatted with Tanvi, Keeler, and Richard and the reason we can't do this for all pages is because it would make pages non-deterministic. HSTS priming will (hopefully) fix the problem for all pages, but at the moment I don't think anything should block us from rolling out mixed content excemptions for pinned domains, or am I missing something?

[1] http://mxr.mozilla.org/mozilla-central/source/dom/security/nsMixedContentBlocker.cpp#639

Comment 14

[Daniel Veditz [:dveditz]]

In the current Fetch spec (https://fetch.spec.whatwg.org/) section 5.1

  step 3 is handle "upgrade insecure" specification
  step 4 is block mixed content
  ...
  step 6 is apply HSTS

There were arguments in public-webappsec that resulted in this specification order. We can re-hash those arguments, but there, not here in a Mozilla-only bug. Unless the spec changes (and has broad browser vendor support for the change) we should not go off on our own.