W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2015

Re: [UPGRADE]: What's left?

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 10 Mar 2015 15:42:26 -0700
Message-ID: <CABkgnnWXdpGbRVxWTsa4VvoL+H1ML2WPQobDNCnuPqqFoXtmKg@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Mike West <mkwst@google.com>, Ilya Grigorik <igrigorik@google.com>, Eric Mill <eric@konklone.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Jeff Hodges <Jeff.Hodges@kingsmountain.com>, Tanvi Vyas <tanvi@mozilla.com>, Yves Lafon <ylafon@w3.org>, T Guild <ted@w3.org>, Daniel Appelquist <appelquist@gmail.com>, Alex Russell <slightlyoff@google.com>, Yoav Weiss <yoav@yoav.ws>, Mark Nottingham <mnot@mnot.net>
Link: <https://equivalent/path>;rel="secure"

Is probably OK.  That means that you have the content from the body of
the response, but you can follow the link to find a secure version.
Then you only have to worry about minimizing the unsecured junk you
are using to base decisions on.

On 10 March 2015 at 14:10, Brad Hill <hillbrad@gmail.com> wrote:
> Totally insane here, and I'm sure it would break all kinds of tools that
> look for literal "200" vs /2\d\d/, but could we create a new HTTP status
> code, 243 or whatever, that means "OK, and this resource also available over
> https"?
>
> On Tue, Mar 10, 2015 at 12:44 PM Mike West <mkwst@google.com> wrote:
>>
>> On Tue, Mar 10, 2015 at 7:18 PM, Ilya Grigorik <igrigorik@google.com>
>> wrote:
>>>
>>> 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.
>>
>>
>> I don't see this as being terribly controversial, but I'll defer to HTTP
>> experts.
>>
>> In my mind, the 200 response indicates that the server was able to
>> correctly serve a response for the request. That response contains data that
>> triggers a navigation to a different page. This isn't substantially
>> different from a JavaScript-driven `window.location` change; we just speed
>> it up because we don't have to parse the page before navigating. It's no
>> different, really, than `Refresh: ...` (not that `Refresh` is a model of
>> sanity, of course).
>>
>>> 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.
>>
>>
>> No. It would be nice if we could upgrade immediately, but I don't think
>> waiting until the second request is off the table.
>>
>>>
>>> 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?
>>
>>
>> Pinning an opt-in that unlocks sending the header doesn't seem to me to be
>> dramatically simpler. It just moves the complexity.
>>
>>>
>>> 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"
>>
>>
>> This would probably work for the positive case (HTTP -> HTTPS). It's not
>> clear that it would work for the negative case (HTTPS -> HTTP). In the
>> former, we could certainly skip the first pageload, get the opt-in, and keep
>> it for subsequent loads. For the latter, it's not clear how we'd distinguish
>> between an initial load and a subsequent load for legacy user agents.
>>
>> -mike
Received on Tuesday, 10 March 2015 22:42:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:11 UTC