Firefox's Mixed Content Blocker is enabled by default in Firefox 23+. It will block Mixed Active Content, but allow Mixed Passive Content (unless the user explicitly turns it off by setting security.mixed_content.block_display_content to true).

If an HSTS site includes Mixed Active Content, we will block the content by default. As Ryan mentioned, a user without HSTS protections is still at risk. This is discussed in detail in this blog post: https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/#Appendix. This has actually been a problem for our own mozilla sites, since many of them have set the HSTS header but haven't updated their content. We are working with them to update their websites and replace http:// links with their https:// equivalents.

Note that our definitions of Mixed Active and Mixed Passive are slightly different than Chrome's and IE's. Some of these differences are also discussed in the blog post (https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23).

Thanks!

~Tanvi



On 5/22/13 3:52 PM, Ryan Sleevi wrote:
On Wed, May 22, 2013 2:56 pm, Daniel Kahn Gillmor wrote:
  hi websec folks--

  I am wondering what people think the proper intersection is between a
  web browser's mixed-content warnings and HSTS.

  For example, if https://example.net has asserted
  Strict-Transport-Security: max-age=15768000 but the homepage at
  https://example.net/ also contains

    <img src="http://example.net/example.jpg"/>

  should an HSTS-compatible browser show its standard mixed-content
  warning even though it knows to rewrite that img src to
  https://example.net/example.jpg ?

  My intuition is that this shouldn't trigger the browser's mixed-content
  warning, but chromium 26.0.1410.43 does show it, and

   https://code.google.com/p/chromium/issues/detail?id=122548#c26

  suggests that palmer@ and rsleevi@ think that is the correct behavior
  because they want:

to signal to the site author of an error - for example, if users which
did not have HSTS visited.
  I'm not sure how the author is supposed to get this signal from the site
  visitor's browser, though -- perhaps the expectation is that site
  visitors will independently report the "broken lock" to the site
  administrator?
Yes.

The view is that it's still a legitimate error for the site operator, in
that any user without HSTS protections (or with expired HSTS) is still at
risk. While HSTS may be providing protection to the user, the site itself
is still configured to serve resources insecurely, thus we still surface
it as user visible.


  I also note that firefox 21.0 (when
  security.mixed_content.block_display_content = true) doesn't show the
  media at all, and when security.mixed_content.block_display_content =
  false it shows the image but removes the lock from the address bar
  (which i think is the equivalent of the "mixed content warning" these
  days).
I believe the Firefox behaviour is an artifact of their current (partial)
implementation of mixed content blocking. According to
https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/
, future versions should distinguish between active and passive content,
and thus more closely mirror the Chromium behaviour by default (namely,
that it will block active content, but not passive content)

  Do other folks have any thoughts about the right thing is to do here?

ISTM that UI behaviours are largely outside the realm of what the IETF
standardizes.

That said, certainly feedback is welcomed on this, and I would love to see
consistent handling (which, AFAIK, we will soon have). I'm just not sure
if this is really a "spec issue".

_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

_______________________________________________
websec mailing list
websec@ietf.org
https://www.ietf.org/mailman/listinfo/websec

Reply via email to