Re: "Mixed Content" draft up for review - HSTS interworking

When designing HSTS, we explicitly decided that HSTS Policy did not apply to
mixed content -- this was a simplifying design decision. [1].

There's a bunch of subtleties in designing the interworking between HSTS and
'mixed content blocking (MCB)' that it seems we're dancing around in this
thread -- here's my attempt at


For MCB, as noted in S 3.1 of the "Mixed Content" draft [2], all 'active
request contexts' and iframe instantiations are candidates for MCB --
regardless of whether the referenced host[:port] is the same as the host
(and port) component(s) of current web origin or not.

[aside: does MCB apply to a resource reference such as <script
src="ftp:foobar.baz"/> ?  i.e. is it scheme-independent? [2] seems to say
'yes' in S 2.1 ]


In contrast, HSTS policy applies explicitly to all ports on the host (aka
domain name), optionally to subdomains thereof, and in the context of
HTTP-based connections only.

Thus HSTS Policy does not apply to 'other-host' (aka 'other-domain')
resource fetches, and does not apply in Dan's example as he notes..

 > [issuing HSTS Policy] doesn't mean the author would never want to include
 > other-domain non-SSL content. [E.g.,] the common case of viewing embedded
 > images in secure GMail

Tho, Ryan's assertion..

 > HSTS from a site operator is a clear indicator that all resources should
 > be HTTPS, and thus failures to adhere to that policy are bugs by the
 > author that UAs should not try to cover up.

..doesn't necessarily apply (per Dan's example).

Given the modern UX treatment of MCB as described in Tanvi's blog [3], I
tend to agree with Dev's and Dan's UX treatment sentiments..

Dan replied:
 >
 > On 6/2/2014 8:41 AM, Devdatta Akhawe wrote:
 >
 >> Further, since showing the mixed content dialog is bad UX, I think "we
 >> will not show mixed content dialog if HSTS is on" is a great carrot to
 >> encourage HSTS adoption, which is what we all want.
 >
 > I agree, there's no point warning the user about something that hasn't
 > happened. We should still spit out a message on the console, of course.

..and Tanvi noted in her msg of "Mon, 02 Jun 2014 13:44:33 -0700" that..

 > In the HSTS case, we have gone back and forth about whether we should
 > warn users when no http network load has occurred
 > (https://bugzilla.mozilla.org/show_bug.cgi?id=838395).  I personally
 > could go either way on this. ... On the other hand, since more browsers
 > are starting to support HSTS, the case to stop warning users grows
 > stronger as more of the population will be protected despite developer
 > mistakes
 > 
(https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Browser_Support).


So..  I think the present ordering in the Fetch spec of the Fetching
algorithm [4]..

   1. Modify request's url per HTTP Strict Transport Security,
      if applicable. [HSTS]

   2. Invoke Mixed Content hook with request.

   3. Invoke CSP hook with request.

   4. ...

..seems overall fine (unless I'm missing something) and I would not re-order
it.

In terms of step 1 in the Fetch alg -- by "Modify request's url per HTTP
Strict Transport Security" I suggest re-writing it more precisely along
these lines..

   1. Determine whether the url refers to a Known HSTS Host by applying the
algorithm given in RFC6797's section "8.3. URI Loading and Port Mapping" to
the request's url. This algorithm handles any needed url re-writing, and is
idempotent otherwise.

Does that resolve this overall mixed-content / HSTS interworking issue?

HTH,

=JeffH


[1] https://tools.ietf.org/html/rfc6797#appendix-A:

    2.  We chose to not attempt to specify how "mixed security context
        loads" (also known as "mixed content loads") are handled, due to
        UA implementation considerations as well as classification
        difficulties.


[2] https://w3c.github.io/webappsec/specs/mixedcontent/


[3] Mixed Content Blocking Enabled in Firefox 23!
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/


[4] http://fetch.spec.whatwg.org/#concept-fetch

Received on Tuesday, 3 June 2014 07:03:05 UTC