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

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

From: Richard Barnes <rbarnes@mozilla.com>
Date: Tue, 5 Jul 2016 13:32:35 -0400
Message-ID: <CAOAcki9GLBw7r0YmEU7r8q-a-BzP0+WgtfgPC0oqi3kceQuZJA@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Chris Palmer <palmer@google.com>, Tanvi Vyas <tanvi@mozilla.com>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Mike West <mkwst@google.com>, Christoph Kerschbaumer <ckerschbaumer@mozilla.com>, "dveditz@mozilla.com" <dveditz@mozilla.com>
I'm finding Brad's arguments pretty convincing.  UIR-FB verges on being
harmful for pages that are "https:" at the top level, since it encourages
half-baked deployment.  There could be some benefit for pages that are
"http:" at the top level, but that's not really a population that I'm
interested in investing in right now.

Net of all that, I would be comfortable letting this proposal drop.

On Fri, Jul 1, 2016 at 3:41 PM, Brad Hill <hillbrad@gmail.com> wrote:

> I agree it creates no new vulnerabilities, but I question the benefits.
> Yes, user agents do and will continue to block insecure scripts.  This is
> exactly the crux. If you got a new cert for your http site that depends on
> external scripts to render important user experiences, make buttons click,
> or just measure the ads that pay to keep you in business, you can't start
> sending users to the https version yet if those scripts don't upgrade.
> This is why I think that it's not realistic to think that Certbot could
> just start flipping the switch automatically.  Modern web apps depend
> deeply on scripts and things will break.
> Certainly there is some population of sites that could benefit from
> UIR-FB.  If the cost to implement is very cheap, let's do it.  If it's not,
> we should try to understand a bit how big that population is.
> On Fri, Jul 1, 2016 at 11:59 AM Chris Palmer <palmer@google.com> wrote:
>> 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 Tuesday, 5 July 2016 17:33:05 UTC

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