Re: Proposal for a MIX Level 2 roadmap.

Thanks for bringing this up Mike! Overall, I think this is a good idea to
reduce mixed content. As the person who implemented HSTS Priming on FF,
there are a couple takeaways that I think this proposal needs to address to
be successful.

1.  Upgrade blockable mixed content to HTTPS by default rather than
> blocking it.
>

The experience with HSTS priming shows that firewalls which drop packets to
the HTTPS port (instead of returning TCP reset) result in extremely long
timeouts, upwards of 30 seconds, depending on the OS. Just upgrading
HTTP->HTTPS is likely to cause problems because of the timeouts. This might
be fine for currently blockable content such as scripts or stylesheets
since they wouldn't load anyway, but they can block the remainder of the
page from loading. HSTS priming added aggressive timeouts of about 2000ms
to deal with this.

Since priming cached the "Negative HSTS Cache", it wasn't necessary to
continually send HSTS priming requests, and priming requests were only sent
for a very small number of requests overall. With a Negative Cache time set
to 1 week, about 0.04% of all requests sent an HSTS priming request. We
didn't have telemetry on whether any of the non-HSTS resources that we
could connect to over HTTPS were the same or different from the HTTP
resources.

This proposal should probably also specify what happens on redirect. For
example, https://example.com/a.html loads http://example.net/b.js, which
gets upgraded to https://example.net/b.js. What happens if
https://example.net/b.js returns a redirect to an http:// script, either
the original or a different one?


> 2.  Treat optionally-blockable mixed content as blockable by default, with
> an opt-in to status quo behavior.
>

We saw that optionally-blockable content is sometimes loaded in response to
user activity, so the page might be secure until they attempt to play the
non-HTTPS audio stream, for example. The opt-in header would work in this
case, but some users and web developers would be very sensitive to the
security indicators going away for no discernible reason.

Thanks,
~Kate

--
Kate McKinley
kmckinley@mozilla.com

2017-10-27 16:07 GMT+09:00 Mike West <mkwst@google.com>:

> Hey folks, as a bit of TPAC prework, Emily and I sketched out some things
> we're thinking about for a second pass at the Mixed Content spec. We'd
> really appreciate y'all taking some time to chew them over so we have
> things to talk about in a ~week. :)
>
> Details are at https://github.com/mikewest/webappsec-mixed-
> content/blob/master/proposed-level-2-roadmap.md. The TL;DR is that we
> think user agents should:
>
> 1.  Upgrade blockable mixed content to HTTPS by default rather than
> blocking it.
>
> 2.  Treat optionally-blockable mixed content as blockable by default, with
> an opt-in to status quo behavior.
>
> 3.  Deprecate and remove `Upgrade-Insecure-Requests` in favor of the above.
>
> 4.  Remove their user-facing blockable mixed content overrides.
>
> Explicitly CCing some folks who I hope will be interested.
>
> Thanks!
>
> -mike
>