Re: [UPGRADE]: What's left?

On Tue, Mar 10, 2015 at 1:15 AM, Mike West <mkwst@google.com> wrote:

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

Yikes. This means that a 200 is now interpreted as a 302, which is breaking
a lot of HTTP semantics... I'll defer to Martin and Mark on this, but it
doesn't smell right.


> 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/` <http://example.com/>
> 2. Server response includes the upgrade directive.
> 3. User agent interprets that directive as a redirect to `
> https://example.com/` <https://example.com/>
> 4. User agent requests `https://example.com/` <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/` <https://example.com/> (without
> an `upgraded: 1` header).
> 2. Server redirects to `http://example.com/` <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. :)
>

Do we absolutely have to invoke the upgrade on initial navigation request?
The proposed redirect dance breaks HTTP semantics and is bound to confuse
people + tooling. Alternatively, if the site simply provided a meta opt-in
tag and the UA would remember this opt-in.. we would avoid these
complications and dramatically simplify this entire flow? Concretely it
would be something like:

1. User requests `http://example.com/`
2. Server (http://) response includes upgrade opt-in (header or meta - e.g.
"Accept-CH: upgrade")
3. (Optionally) User agent can immediately upgrade subresource requests to
https:// after processing the opt-in
4. User agent remembers opt-in and advertises "Prefer: upgrade", or some
such, on future requests (nav and resources) to same origin
  a) Site can redirect the user to HTTPS (via 3XX) based on presence of
"prefer: upgrade"
  b) Site can lock-in the user into HTTPS (to avoid further 3XX overhead)
via HSTS based on presence of "prefer: upgrade"

ig


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