W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2016

Re: [UPGRADE] upgrade-insecure-request-with-fallback

From: Chris Palmer <palmer@google.com>
Date: Fri, 1 Jul 2016 11:59:33 -0700
Message-ID: <CAOuvq23wT-TSL39bvvzfQ14ALkBGwBQVNB_N_PjDQAwfzfNh7Q@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Tanvi Vyas <tanvi@mozilla.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Richard Barnes <rbarnes@mozilla.com>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, "dveditz@mozilla.com" <dveditz@mozilla.com>
I'm less concerned about non-secure script in an otherwise-secure page,
because good UAs block it outright anyway. Point your favorite browser at
https://mixed-script.badssl.com/, for example. Desktop Firefox and Chrome
refuse to load the non-secure script, but have an option to let the person
load it anyway (with suitably frightening messaging); Safari and Chrome for
iOS, and it seems Safari for desktop, don't even have that option. IE makes
it a bit too easy to load the non-secure script for my tastes, but even so
it's safe by default. And most browsers do still distinguish fully-secure
page-loads from those that have some mixed display content.

So, assuming a good UA, UIR-FB seems to be much more of a win for HTTPS
deployment than a safety risk.

My boundless optimism ;) allows me to hope that the slowness of the 2
round-trips (as Tanvi mentioned) would be incentive enough for
some/many/most site operators to use UIR-FB only as a temporary aid and not
a permanent mode of deployment. Surely, some will leave it permanent, so
we'd still have to do all the usual outreach and evangelism.

I don't relish latency, evangelism, or complexity, but I don't see that
UIR-FB creates a new vulnerability, and the benefits could be substantial.
Received on Friday, 1 July 2016 19:00:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:56 UTC