Re: [UPGRADE] Consider plan B for reduced complexity?

FWIW, I like this general direction. 

The upgrade spec's relationship to HSTS is confusing despite the explicit section about that in the spec, and having two things that do such similar things specified in such different ways just increases the cognitive load for the poor people trying to deploy this (and I note the low numbers of adoption for both HSTS *and* CSP, e.g., on builtwith.com).

Defining this in terms of a modification to HSTS semantics is much easier to explain and understand.

Also - FWIW HSTS doesn't make the distinction you do below; it says:

"""
Whenever the UA prepares to "load" (also known as "dereference") any "http" URI [RFC3986] (including when following HTTP redirects [RFC2616]), the UA MUST...
"""

I think it's drawing a very long bow to think that that only applies to user navigation and not subresource dereferences. And, doing a quick test, I find that Chrome and Firefox won't load <http://www.mnot.net/lib/script.js> when HSTS is in use, but Safari will. 

So arguably Chrome and Firefox aren't conformant to HSTS -- or more likely, the relationship between mixed content and HSTS hasn't been properly specified (as the HSTS spec alludes to).

In a perfect world, this would have been all figured out before HSTS was deployed. As it is, I like Dan's proposal more than upgrade-insecure-requests (but will continue to give feedback on the latter regardless).

Cheers,


> On 7 Mar 2015, at 5:11 am, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> 
> Hi webappsec--
> 
> pde and I were looking at UPGRADE today, and (as noted in pull request
> #209) noticed that Prefer: return=secure-representation is going to need
> to be sent for all navigational requests if we want to make HSTS
> conditional on this behavior.
> 
> This also makes HSTS itself contingent on the browser in use, which
> means that services which scan for HSTS headers and compile them into
> lists for client use will be more complex.
> 
> In light of this complexity maybe we should consider a plan B, which
> should accomplish the same goals while needing less network traffic and
> better encouraging HTTPS and HSTS adoption.
> 
> Here's a strawman:
> 
> * create a new HTTP Response header, HSTS2.  HSTS2: has the same
>   semantics as Strict-Transport-Security:, except that it should only
>   be implemented by clients that do opportunistic upgrade of blockable
>   mixed content (that is, they try a secure upgrade for subresources
>   instead of blocking insecure content).
> 
> New clients can do opportunistic upgrade of blockable mixed content on
> any secure connection.  Server operators can choose to opt into either
> Strict-Transport-Security: or HSTS2:, depending on whether their sites
> require this upgrade of blockable mixed content to work securely.
> 
>    --dkg
> 
> 

--
Mark Nottingham    mnot@akamai.com    https://www.mnot.net/

Received on Friday, 13 March 2015 04:49:14 UTC