Re: [UPGRADE]: What's left?

On Sun, Mar 8, 2015 at 8:54 PM, Eric Mill <eric@konklone.com> wrote:

> On Sun, Mar 8, 2015 at 7:41 AM, Peter Eckersley <pde@eff.org> wrote:
>
> >> Option #2: UA sniffing. No one likes this, but, since sites are probably
> >> sniffing for a variety of reasons anyway, why not add one more? This has
> >> the disadvantage of being ugly, but the advantage of not (further)
> bloating
> >> request/response headers.
> >>
> >> At a higher level, _how important_ is it that we deal with #4?
> >
> > I would classify the importance of dealing with #4 cleanly as pretty
> > high.  If a site gets this wrong, and sets HSTS on a client whose MCB
> > implementation breaks the site, that's going to be a source of extremely
> > persistent and pernicious problems.  Perhaps such a broken state is
> > recoverable, but only if the site can tell which subpopulations it has
> > broken, and unset HSTS for them (by setting HSTS with maxage 0).
>
> If a site is smart and security-conscious enough to:
>
> * set a CSP header at all
>

Tiny nit: I don't see this as a prerequisite. I'd expect a site like BBC's
archive (which does not currently set a CSP header) to be able to
copy/paste `Content-Security-Policy: upgrade-insecure-requests` from the
spec and be perfectly happy doing so without any additional side-effects.


> * set a new CSP header for upgrading mixed content
> * conditionally redirect clients that don't support the upgrade spec
> down from HTTPS to HTTP
>

As an aside, it occurred to me overnight that we can avoid the redirect
(and the signal) for HTTP pages if we interpret the presence of an
`upgrade-insecure-requests` directive in an insecure response as asking for
the resource itself to be upgraded. Filed
https://github.com/w3c/webappsec/issues/212 to explain a bit, and think
about this some more.


> * understand why the tradeoffs and implementation work make sense for
> their body of legacy content
>
> ...then I think they can probably also evaluate the effect of HSTS on
> their website under these circumstances.
>
> This whole upgrade spec is about providing a long-term migration path,
> right? Where we expect browser update cycles to outpace the ability of
> a website with a large body of content to go through and upgrade the
> resource links?
>

This is a great way of phrasing the way that I've been approaching the
problem, thanks, Eric!


> It could be that the tradeoff here is that HSTS is effectively not
> advised until the presence of legacy clients that don't support the
> UPGRADE spec diminishes to an acceptable amount. At that time, a
> website can shut off the HTTPS->HTTP downgrade, and add HSTS, at the
> same time. The UPGRADE spec could recommend this strategy.
>

This is what I was trying to get at in my previous email. I see HSTS as
putting a cap on an otherwise pristine TLS configuration, and
pinky-swearing to the user agent that you're going to keep it running for X
seconds. Given that we're talking about sites that are in the middle of a
migration process, and that we're presupposing that they're going to have
both an HTTP and HTTPS version of the site running alongside each other,
it's not clear that setting HSTS is going to be high on their priority
lists.

In the other thread, I'm even going to argue that this is an advantage of
UPGRADE over HSTS2, as the former is representation-specific, which allows
authors to make granular decisions about which pages can safely be
upgraded, without locking themselves into something for a long time.

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