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