STS and "mixed content" (Part 3 of Re: Feedback on the Strict-Transport-Security specification)

I've extracted the "mixed content" (aka "mixed http/https-conveyed content", 
aka "mixed security origins") stuff from Adam's reply to EricLaw's feedback. My 
comments are at the end.

Adam replied:
 >  EricLaw said:
 >
 >> I am a bit concerned that the spec doesn't mandate behavior for
 >> mixed-content; I know such requirements would be controversial and
 >> non-trivial, but without the behavior being mandated by the spec, I think
 >> we're likely to see divergent and incompatible behavior on STS sites.
 >
 > There's a tension about what to put in STS and what is more
 > appropriate for a more general policy delivery mechanism, like
 > Content-Security-Policies <https://wiki.mozilla.org/Security/CSP>.
 > The main reason not to include STS in CSP that the browser needs to
 > know the STS policy before it receives the CSP header because the
 > browser needs to hand errors during the SSL / TLS handshake.
 >
 > In the case of mixed content, we can wait until we receive an HTTP
 > header, so we don't need to play tricks with time scoping (i.e.,
 > Max-Age) or URL scoping (i.e., includeSubDomains).  I'd like to see
 > browser vendors expose policy levers for controlling mixed content,
 > but I'm not sure whether STS or CSP is a better home for that
 > directive.


Adam replied:
 >  EricLaw said:
 >
 >> [Section 10: UA Implementation Advice; Section 2.4.3: Ancillary
 >> Requirements;] This portion of the spec troubles me the most. I was
 >> looking forward to this spec settling things once and for all and
 >> requiring mixed content to be treated as a fatal error. However, the spec
 >> doesn't require that, and thus I think it's missing out on an absolutely
 >> critical opportunity. If UAs differ in behavior (e.g. IEvN silently blocks
 >> "without recourse" mixed content but Firefox does not) then it's likely
 >> that users and developers will erroneously conclude that the more secure
 >> UA is "broken" or "buggy."
 >><http://blogs.msdn.com/ieinternals/archive/2009/06/22/HTTPS-Mixed-Content-in-IE8.aspx>
 >
 >
 > I responded to this at the top of the email [see above]. There seems to be
 > some amount of support for making STS imply blocking mixed content. If you
 > think this is what we should do, then we can do it. One concern I have here
 > is that browser's mixed content detection is notoriously buggy, but maybe
 > this requirement will motivate us to get it right.
 >
 >> Having noted this, I do need to observe that controlling mixed content is
 >> harder for IE than for any other browsers, because IE requires add-ons to go
 >> directly to the network stack (WinINET/URLMon) while competitive browsers
 >> typically expect that the add-on will use NPAPIs to request that the host
 >> browser collect data on their behalf.
 >
 > This picture is actually even less rosy.  Some popular NPAPI plug-ins
 > use a mix of browser-provided and OS-provided networking services
 > because the NPAPI network APIs lack some basic functionality (like
 > setting headers on GET requests).
 >
 >> Other cases of "mixed" content: the WebSocket specification, which supports
 >> both secure and insecure modes.  Ditto for FTP/FTPS.
 >
 > and CORS.  There's a lot of complexity to mixed content.


Some initial thoughts come to mind...

Specifying banishment of "mixed http/https-conveyed content" in the STS spec 
itself is relatively easy I think (offhand). And I also believe that it is 
something we should consider incorporating.

Though, UAs already have some amount of "mixed http/https-conveyed content" 
detection and notification functionality. Could the STS-imposed banishment of 
such "mixed security origins" be relatively easily implemented by modeling it 
as if the user selects to ban non-securely-conveyed content (without actually 
being prompted to make this decision), and otherwise relying on the already 
existing functionality in the UA?

After all, each UA that already has detection and notification of "mixed 
http/https-conveyed content" will be needing to (for some individually 
prioritized definition of "needing to") maintain and enhance such functionality 
in the face of the above noted issues (both current and nascent).

And if all UAs that already have such detection and notification uniformly 
don't allow for user recourse if STS policy is set, then that'd seem to address 
EricL's concerns about at least user-visible differences between UAs.

Of course, some UAs would effect such a ban better than others, but my hope is 
that not effectively implementing (under-the-hood) such a ban (e.g. in the face 
of the above mentioned issues with plugins/extensions) would then be regarded 
even more clearly as bugs (and hopefully cleaned up over time).

thanks,

=JeffH

Received on Wednesday, 16 December 2009 18:49:34 UTC