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.)Received on Tuesday, 10 March 2015 08:16:33 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:47 UTC