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

Just FYI, that the websec WG in the IETF is basically in the process of
being decommissioned, so getting a standards-track RFC number for an
updated HSTS draft isn't likely to be a quick exercise.

On Thu Feb 05 2015 at 11:47:14 AM Mike West <mkwst@google.com> wrote:

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