Re: [UPGRADE]: What's left?

On Mon, Mar 9, 2015 at 11:07 PM, Ilya Grigorik <igrigorik@google.com> wrote:

> On Mon, Mar 9, 2015 at 8:19 AM, Mike West <mkwst@google.com> wrote:
>>
>> 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.
>>
>
> "client should behave as though it received a redirect response to
> https://example.com/" ... what does that mean exactly? As in, the UA
> should treat it as a 302 and transparently initiate a new request?
>

Yes.


> Would it remember this for subsequent navigations?
>

No (except insofar as we upgrade navigational requests made from a page
where the header is present: see example #2 under
https://w3c.github.io/webappsec/specs/upgrade/#examples).


> Re, avoiding UA sniffing: have you considered an opt-in strategy for
> delivering the header? In CH we have "Accept-CH" [1] which acts as a signal
> for the UA to advertise its capabilities to the server.. this allows the
> site to opt-in without burdening the rest of the web with the same
> on-by-default header.
>
> [1]
> https://tools.ietf.org/html/draft-grigorik-http-client-hints-02#section-2.2.1
>

I now think we can avoid the signal entirely for HTTP pages by treating the
response header as a request for redirection, as discussed above.

If we have that in place, perhaps we could reverse the signaling by adding
an `upgraded: 1` header for requests that were rewritten on the client-side
from HTTP to HTTPS. That is:

1. User requests `http://example.com/`
2. Server response includes the upgrade directive.
3. User agent interprets that directive as a redirect to `
https://example.com/`
4. User agent requests `https://example.com/`, and includes an `upgraded:
1` request header.
5. Server sees that header, says "Hooray!", and locks the user into HTTPS
via HSTS.

This clearly addresses the "modern client" use case, and could be abused to
address the "legacy vs modern" use case for those sites that _really_ care
if we're willing to suffer another redirect:

1. User requests `https://example.com/` (without an `upgraded: 1` header).
2. Server redirects to `http://example.com/`.
3. If the user's client supports upgrades, goto #1 above.
4. Otherwise, stay on sad, old HTTP.

I expect Ilya's head to explode while reading this ("Two redirects?! Are
you MAD!?"). It solves the problem, but isn't pretty, and isn't something
I'd hope that most sites care about. :)

(I'll copy/paste this into the GitHub issue (
https://github.com/w3c/webappsec/issues/212), as I'd like to start taking
some details of our discussions there; it seems to have worked pretty well
for the WebApps group in the recent past)

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