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

Re: [UPGRADE]: What's left?

From: Peter Eckersley <pde@eff.org>
Date: Sun, 8 Mar 2015 04:41:40 -0700
To: Mike West <mkwst@google.com>
Cc: "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>, Ilya Grigorik <igrigorik@google.com>, Yoav Weiss <yoav@yoav.ws>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150308114140.GG7934@eff.org>
On Sun, Mar 08, 2015 at 12:12:49PM +0100, Mike West wrote:
> 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?

I believe so, yes.

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

Yes, though as I noted in that subthread it will still be necessary to
send the Prefer header very occasionally even if the client has HSTS set, just
to make sure HSTS is renewed.  That gives a long-term path to removing
the cruft from a bytes-on-the-wire perspective, though the semantic
complexity will be with us for a long while.


> Are there other ways
> we could limit the scope of the header for HTTPS pages that would be
> effective?

Dkg suggested one alternative approach in another thread.  It's quite
different, in that it makes the upgrade-insecure behaviour a default
with opt-out for sites rather than opt-in.  Probably best worked up as a
separate plan of its own, and then compared if and when it's mature.

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

I would classify the importance of dealing with #4 cleanly as pretty
high.  If a site gets this wrong, and sets HSTS on a client whose MCB
implementation breaks the site, that's going to be a source of extremely
persistent and pernicious problems.  Perhaps such a broken state is
recoverable, but only if the site can tell which subpopulations it has
broken, and unset HSTS for them (by setting HSTS with maxage 0).

For these reasons, UA sniffing is unusually inadvisable as an
implementation strategy for #4.
-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
Received on Sunday, 8 March 2015 11:42:12 UTC

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