Re: [UPGRADE]: What's left?

On Sat, Mar 7, 2015 at 11:36 AM, Peter Eckersley <pde@eff.org> wrote:

> On Fri, Mar 06, 2015 at 07:43:55PM +0100, Mike West wrote:
>
> > I don't understand why HSTS needs to be conditionally set. Presumably
> > you're only redirecting "safely upgradable requests" to HTTPS if you're
> > this spec's target audience.
>
> It's very important that HSTS be conditionally settable, because even if
> the site itself only conditionally redirects to HTTPS, inbound links
> from other sites will send old clients to the HTTPS site, and they'll
> pick up the HSTS header that way.
>
> Now that I think about it, some sites will also need to serve
> conditional downgrade redirects from HTTPS -> HTTP if the header is
> absent, in order to preempt mixed content breakage :(


Ok. Let's walk through the top-level navigational scenarios to see if we
can address them reasonably. If we assume that a given site supports HTTPS
only for upgrade-capable clients, and that we can't touch the page's
content, then:

1. Upgrade-capable user agent navigates to HTTP: this client should be
redirected to HTTPS, and HSTS should be asserted.
2. Upgrade-capable user agent navigates to HTTPS: this client should remain
on HTTPS, and that HSTS should be asserted.
3. Legacy user agent navigates to HTTP: this client should stay on HTTP.
4. Legacy user agent navigates to HTTPS: this client should be redirected
to HTTP, and HSTS should not be asserted.

My understanding is that the current proposal deals with all of these well
except #4. Is that an accurate summary?

If so, how can we deal with #4?

Option #1: Add some sort of upgrade-capable signal
('return=secure-representation', 'upgrade-capable:1', 'secure: please', or
any of a number of other spellings) to every navigational request, HTTP and
HTTPS. I think this would end up as mandatory cruft, pretty much forever.
I'm not a fan of that (but I'm willing to be convinced that it's
necessary). Martin's suggestion that we suppress the signal if HSTS is
enabled for a host might limit the long-term impact. Are there other ways
we could limit the scope of the header for HTTPS pages that would be
effective?

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? If an author
is worried that their site will be unacceptably broken over HTTPS for
clients that don't support upgrades, perhaps she can simply choose not to
serve HSTS headers until she's fixed the hard-coded resource links. In the
short-term, upgrade-capable clients will be secure most of the time (and
this could be mitigated by asking the friendly agl@ to pin HSTS state in
Chrome even though she's not delivering it), and older clients will remain
old.

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