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

UPGRADE: Feature detection?

From: Mike West <mkwst@google.com>
Date: Wed, 11 Feb 2015 15:34:37 +0100
Message-ID: <CAKXHy=fqCRTjHWZ1_ag7xzWa-PTxD2KwvPZ3hK6mS=5zZJos6w@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Cc: Peter Eckersley <pde@eff.org>, Eric Mill <eric@konklone.com>, Jacob S Hoffman-Andrews <jsha@eff.org>
While writing the example flow at
https://w3c.github.io/webappsec/specs/upgrade/#examples, I stumbled over
the problem of knowing when to redirect a user from an HTTP page to an
HTTPS one. If you require the upgrade mechanism we're defining in order to
give a user a reasonable experience, then you need to know whether or not
she's capable of performing the upgrade before redirection.

I think we should explicitly support this sort of feature detection, rather
than relying on user agent sniffing*. Perhaps something like the following
HTTP request header could be sent along with every navigational request
(e.g. top-level navigations, new windows, and iframes):

    Accept-Upgrade: https

Servers could inspect the headers of the request, and decide based upon the
presence of that header whether or not they were dealing with a client that
could transparently upgrade requests. If so, redirect to HTTPS if you're
not already there, if not, redirect to HTTP.

WDYT?

*Eric Mill and Jacob Hoffman-Andrews noted thre issues with UA detection in
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0052.html and
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0049.html,
but I didn't recognize the impact at the time. Sorry for the delay!

--
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 Wednesday, 11 February 2015 14:35:25 UTC

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