On Thu, Feb 5, 2015 at 12:14 AM, Peter Eckersley <pde@eff.org> wrote: > Unfortunately, I think that does mean that both HSTS and the proposed new > CSP upgrade flag should have the overlapping effect of upgrading > navigational HTTP requests to the domains that set them. > 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. If you're really unhappy about that overlap in functionality, WDYT about > implementing the exact same "Pretty Secure For New Clients" state as a > "Helpful" or "Easy" directive to the HSTS header, rather than a new CSP > directive? 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. That said, upgrading a set of links for a specific page, without upgrading those links for all other pages on the net, seems like a better fit for CSP than for HSTS, and seems like it solves the main thrust of the mixed content problem you outlined in https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0023.html. -- Mike West <mkwst@google.com>, @mikewest Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 5 February 2015 07:29:04 UTC