- From: Peter Eckersley <pde@eff.org>
- Date: Tue, 17 Mar 2015 18:12:56 -0700
- To: Mike West <mkwst@google.com>
- Cc: 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 10:06:02AM +0100, Mike West wrote: > On the issue of downgrades: I'm reluctant to add a header to every secure > navigational request as well (as suggested in > https://github.com/w3c/webappsec/pull/209), as I don't see how we'd ever be > able to remove them once added. I've updated the #209 pull request to create an eventual path toward retirement of the header, once sites deploy HSTS. WDYT about that solution? It seems to have about the same retirement properties and horizon as #212, without being quite as nuts. > I agree that the downgrade procedure I > proposed in https://github.com/w3c/webappsec/issues/212 is nuts. I don't > have a good answer here other than UA sniffing (which, really, I don't > think is that bad of an option). UA sniffing is a survivable hack for sites that just want to do HTTPS-for-new-client, HTTP-for-old, but it's rather dangerous in combination with HSTS. Fortunately the user populations that tend to mess with UA switchers also probably tend to update their browsers, but I'm sure there'll be lots of complaint emails from exceptions. And having that impediment to HSTS deployment would be a bad thing, because it would leave a lot more sites vulnerable to first connection hijacking and to cookie theft attacks. -- 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 01:13:32 UTC