Re: HSTS, mixed content, and priming

> On Aug 24, 2015, at 11:24 PM, Brian Smith <brian@briansmith.org> wrote:
> 
> Richard Barnes <rbarnes@mozilla.com> wrote:
>  
>  
>> As mentioned above, the primary value is to remove the indeterminacy around HSTS upgrades, so that it's safe to treat HSTS ugprades as not mixed content.
> 
> There is no safety issue here.
> 
> Consider http://foo.example.org/ which embeds a subresource from http://bar.example.org/. Assume bar.example.org is HSTS. Then the browser will already request https://bar.example.org/ instead of http://bar.example.org.
> 
This is a good point.  There is already inconsistent behavior on HTTP pages with HSTS subresources, so is it a big deal to have the same inconsistency on HTTPS?

> The fact that the same doesn't happen for https://foo.example.org/ (i.e. the mixed content case) is mostly due to the fact that the mixed content blocking decision is made before HSTS upgrades are done instead of after. In particular, if Firefox had done HSTS rewriting before it did mixed content checks then I am pretty sure nobody would have done extra work to reverse the order of those checks.
> 
>> So relative to u-i-r, this reduces uncertainty for site operators, and gets more HTTPS faster (since it's a partial ugprade).  It seems like these two are complementary in much the same way that HTTPS and HSTS are -- you can turn on HTTPS for some parts of your site, then turn on HSTS to lock it in.  Relying on priming to upgrade what can be upgraded of your site on day 0, then once you're sure that all your sub-resources can upgrade properly, turn on u-i-r.
> 
> Neither "priming" nor u-i-r are secure against an active MitM so websites cannot rely on them for security. Websites need to use https:// subresource links to actually be secure.

How so?  Neither priming or u-r-i has to make an HTTP request. The browser makes an HTTP request only when priming fails.