Re: Proposal for a MIX Level 2 roadmap.

On Fri, Oct 27, 2017 at 10:53 AM, Kate McKinley <kmckinley@mozilla.com>
wrote:

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

Thanks for the feedback, Kate, and for the additional details regarding
Firefox's HSTS Priming implementation!

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

The fact that this was common enough to show up in bug reports against HSTS
Priming worries me a bit. I think this proposal would be marginally
lower-risk, as sites that know they're going to load optionally-blockable
mixed content (like image search pages on Google and Bing) could opt-into
status quo behavior with regard to mixed content, trading their address-bar
status for the ability to load mixed images, etc. My hope is that we'd be
left with only accidental inclusions, which presumably developers would be
interested in fixing?

Still, I'd like to ensure that users aren't sitting around for 30 seconds
waiting for script and style to load. Some sort of reasonable timeout on
socket connection seems like a good mitigation, but "reasonable" over
mobile connections is going to be a bit different than "reasonable" on a
desktop machine. Hrm.

Another option would be to force these scripts to be `async`, though that
might also result in breakage of a different sort.

I've added this as a discussion question to
https://github.com/mikewest/webappsec-mixed-content/blob/master/proposed-level-2-roadmap.md#questions.
Thanks!


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

I see. I suppose we could add a similar concept for HTTPS connections in
general: if we try and fail to connect to a given server on a given port,
we could stop upgrading (and just block) for some timeout period.


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

My colleague did some research in this direction earlier this year, which
we're still trying to actually sit down and write up. It looked like a
relatively small percentage of scripty resources had different content over
HTTP and HTTPS, much of which was due to pages whose HTTPS version was a
404 error, noting that the HTTPS version didn't exist.


> 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?
>

We'd upgrade each of the redirects in turn. I imagine this working just as
UIR works today.

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

The opt-in header proposal would unlock status quo mixed content behavior
at the cost of degrating the page's security indicators by default. We'd
avoid the indicator shifting status by just marking the page as having
optionally-blockable mixed content to begin with.


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