Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

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