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

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

From: Brad Hill <hillbrad@gmail.com>
Date: Fri, 01 Jul 2016 19:41:14 +0000
Message-ID: <CAEeYn8h3c+vTXf=Uf-3Ya+1jds6hQ5ps3s=pMWcwE499SMCPqA@mail.gmail.com>
To: Chris Palmer <palmer@google.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 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 Friday, 1 July 2016 19:41:53 UTC

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