- From: Peter Eckersley <pde@eff.org>
- Date: Tue, 3 Feb 2015 02:01:43 -0800
- To: Mike West <mkwst@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "Eduardo' Vela <Nava>" <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Ryan Sleevi <sleevi@google.com>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>
On Tue, Feb 03, 2015 at 10:41:08AM +0100, Mike West wrote: > Right. All good questions. > > My intuition is that if a site is already setting HSTS, and includes > insecure resources, then they're already living with brokenness. Breaking > them in a different way (by failing to load HTTPS resources) doesn't seem > substantially worse (though might have negative performance impacts, > assuming a failed connection takes some amount of time to timeout). > > Using HSTS as a signal almost certainly doesn't solve the adoption problem; > no one is sending the HSTS header unless they've already done substantial > work to get ready. This would simply be a mechanism of ensuring that the > effort was well-spent, and had the desired effect. In the context of the Let's Encrypt Agent (https://www.youtube.com/watch?v=Gas_sSB-5SU), we are hoping to offer an automated deployment path for site operators who run the agent on their webservers. That software will be able to fetch and install certs for them, and that will be fine. If we try to add a 30x redirect, MCB will start firing and everything will break. We wish we could turn on HSTS or a similar mechanism for the admin in order to fix that situation. If the user showed up with a pre-MCB client like Chrome 20 or Firefox 22, it would in fact work, at least for same-origin mixed content; and I'm hoping we can get it to work that way again in the future :) -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Tuesday, 3 February 2015 10:02:13 UTC