- From: Peter Eckersley <pde@eff.org>
- Date: Thu, 5 Feb 2015 11:25:16 -0800
- To: Mike West <mkwst@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Ryan Sleevi <sleevi@google.com>, Eduardo' Vela <evn@google.com>, Wendy Seltzer <wseltzer@w3.org>, Adam Langley <agl@google.com>, WebAppSec WG <public-webappsec@w3.org>
On Thu, Feb 05, 2015 at 08:28:14AM +0100, Mike West wrote: > Isn't this problem dealt with relatively well via simple redirects? > > Yes, redirects can be MitM'd, and pinning would solve that. If you wish to > avoid that problem, asking for "strict transport security" seems like the > right thing to do. Watering down the meaning of that term might increase > adoption to some extent, but I'm not sure it's worth the complexity. I would say that trying to use 30x redirects for upgrading navigational HTTP requests is more or less exactly as secure as reverting from mixed content blocking to the old "broken lock" icon UI. Which is to say, an active attacker can do extremely bad things which only the most sophisticated and attentive users have any hope of detecting. > > I'm not at all dogmatic about where what should be. It's worth talking to > IETF folks in https://tools.ietf.org/wg/websec/ to see if there's interest > in extending HSTS in this way, and if that's a better place for the > functionality, then let's throw away this upgrade strawman. I don't care deeply where this goes either; I think my first and second concerns are that it happens somewhere and as swiftly as we can manage. A tertiary concern is that we get separation for developers between "insecure", "basically strong security but only for newer, helpful clients" and "maximum security everywhere with no way for users to click through warnings if security breaks" as neat as possible. -- Peter Eckersley pde@eff.org Technology Projects Director Tel +1 415 436 9333 x131 Electronic Frontier Foundation Fax +1 415 436 9993
Received on Thursday, 5 February 2015 19:25:46 UTC