W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

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

From: Peter Eckersley <pde@eff.org>
Date: Wed, 18 Mar 2015 09:56:09 -0700
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mike West <mkwst@google.com>, David Walp <David.Walp@microsoft.com>, Tanvi Vyas <tanvi@mozilla.com>, Crispin Cowan <crispin@microsoft.com>, Dan Veditz <dveditz@mozilla.com>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Eric Mill <eric@konklone.com>
Message-ID: <20150318165609.GH881@eff.org>
On Tue, Mar 17, 2015 at 09:27:51PM -0700, Martin Thomson wrote:

> Maybe you could summarize the solution so we don't have to go
> grovelling around in diffs of HTML to make sense of it.

My apologies.  Overall that pull request suggests that the header should
be sent for three purposes:

1. to trigger HTTP->HTTPS upgrades for sites that will need the
upgrade-insecure mechanism

2. to conditionally and safely set HSTS only for clients that support
the mechanism

3. to trigger downgrades from HTTPS->HTTP for clients that are likely to
experience mixed content breakage

Prior to the pull request, it was only sent for purpose 1.

The recent additions to the pull request are an attempt to implement
something you suggested earlier, which is having a retirement path for
the header once HSTS has been set:

https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0017.html

The retirement path turns out to have a few corner cases (one of which I
just noticed and fixed a few minutes ago) but they don't seem too
inellegant.

> 
> What I'm reading is:
> 
> 1. if you have the csp directive set, make the http:// requests anyway, but

The CSP directive is per-page; if a client sees it and understands it,
it will always upgrade both subresources and navigational HTTPS
transitions away from that page to HTTPS.

I believe Mike has been reluctant to upgrade the first request because
he doesn't want to duplicate HSTS, doesn't want the housekeeping of a
per-domain state to keep track of, and (perhaps) wants to preserve the
ability to deploy on some subset of resources on an origin, though the
navigational upgrades complicate that a little.

<snip>

 
> The idea being that nothing special happens unless the UA supports
> this mechanism.  And then, only as long as they are willing to make
> that initial request in the clear.  Once that is gone and we are in
> whatever utopian future doesn't have http:// any more, it's OK to drop
> the prefer: foo.

In the utopian future, you can think of the header being sent
occasionally, and having the semantics "hey, please send me a new HSTS
header with a new max-age to confirm that we aren't dreaming, we really
do live in the utopian future".

This has the nice side effect of being a reliable way for the server to
know when it should to put that extra 50-60 byte HSTS header in its
responses.

> 
> I guess if a site goes full-HSTS, prefer: foo goes away too, but I
> can't see how to detect that.  

One piece of that was missing in the pull request until just now.  Add a
new HSTS directive, "mixed-safe".  If the client sees "mixed-safe" in
the HSTS state, it knows it doesn't need to send the header to that
origin again, unless it wants to trigger an HSTS refresh.

If HSTS is preloaded the client will never need to send the header to a
mixed-safe origin, ever.

> Vary: prefer might be used (actually
> it's arguably needed) as a signal there.
> 
> (Prefer: tls carries the wrong connotations, I think.)

The header now seems to be HTTPS: 1

https://github.com/w3c/webappsec/issues/216

> 

-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
Received on Wednesday, 18 March 2015 16:56:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC