Subject: [websec] Strict-Transport-Security and mixed-content warnings

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 22 May 2013 17:56:28 -0400

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?

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

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

       --dkg

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 22 May 2013 15:52:52 -0700

>  visitors will independently report the "broken lock" to the site

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.

>  (which i think is the equivalent of the "mixed content warning" these

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

---

From: Tanvi Vyas <[email-masked]>
Date: Wed, 22 May 2013 16:26:15 -0700

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:
> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 22 May 2013 23:27:04 -0400

> is still configured to serve resources insecurely, thus we still surface

It is an error for the site operator, certainly.  But for a given user,
with a browser that supports HSTS, which has received the header during
the main page load (so it is clearly not expired), and trying to fetch
content from the origin site itself (that happens to be mistakenly
linked with http:// instead of https://): in this scenario it is not a
security vulnerability for this user.

My expectation as someone who browses the web is the browser UI feeback
info is telling me things about *this connection right now*.  If i want
to get feedback about how the site is (mis)configured in ways that are
not actively harming my connection at the moment, i expect that to be
functionality provided by an extension or a web-developer-specific setting.

For example, if i'm visiting a web page that is not valid HTML, but my
browser can do a passable rendering of it, i don't expect my browser to
choke or provide a warning label that says "invalid HTML! some other
browsers might not be able to render this properly!"  (though maybe that
would be nice?)  What about sites that are using 768-bit RSA keys --
some TLS stacks might reject those too, even if this one does not;
should the browser show a warning?  What about "transvalid" certs, which
are only valid because we were able to find their intermediary CA in our
cache of previously-seen CAs?

There are lots of potential "your current connection is only safe
because of this quirky combination of your browser, the page you're
currently viewing, and your browsing history..." scenarios.  Why should
HSTS+mixed-content be singled out for special display to the user?

I would expect that site administrators don't want their visitors to see
indicators of security failure when they are using tools that are
specifically designed to be able to prevent the security failure in
question from happening.

Site administrators should *also* be happy to have a mechanism to get
reports about possible breakage on non-STS-compatible browsers, but i
don't think they would want that mechanism to be complaints from scared
users of STS-compatible browsers who actually don't have a problem.

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

Some IETF specs do mandate certain UI (e.g.
https://tools.ietf.org/html/rfc6797#section-12.1 specifies "no user
recourse"), so i hope it's not too far outside the scope of the WG to
talk about this here.

But mainly i was asking about this here because i expect folks in this
WG to have thought about these issues and to be able to explain where
they're coming from (and even be interested in working toward rough
consensus).  That already is happening, so i don't think this is a
terrible venue for the discussion :)

Regards,

	--dkg