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

On Thu, Feb 5, 2015 at 8:25 PM, Peter Eckersley <pde@eff.org> wrote:

> 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.
>

Of course, I'd agree. I think you've convinced me that it's reasonable to
bundle first-party navigational upgrades with the CSP directive, as it is
neatly scoped to a page that's opted-into this amazing new behavior.

Navigations from third-parties are more difficult for me to square with the
approach I've proposed, especially given that HSTS exists and is widely
deployed. If you're wish to defend against downgrade attacks, it's right
there waiting for you. I don't really understand why a light version is
necessary, since all of its hard-failure properties that you've noted go
directly towards making the stripping attack impossible, and malicious
replacement difficult.

> 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.
>

"Swift" is probably not something either the IETF or W3C can reasonably
promise. :) That said, this is a simple feature, and I slapped together a
prototype implementation this morning that I might be able to land behind a
flag next week (https://codereview.chromium.org/901903003). The response on
the intent to implement thread has been remarkably positive (
https://groups.google.com/a/chromium.org/d/msg/blink-dev/rjeFL53OV4I/_NvMh0_qsWEJ
).

+Ryan Sleevi, Mark Nottingham, and Martin Thomson, who all are
significantly more active in the IETF than I, and could help you find the
right folks to talk to there to evaluate what would need to happen to
change HSTS.


> 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.


I think the CSP proposal does everything you want except upgrading incoming
links from third-parties. Would you agree with that?

--
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.)