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

On Fri, Jul 01, 2016 at 07:41:14PM +0000, Brad Hill 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.

There are few possible switches here: (1) enable existing UIR, (2) enable an
HTTP -> HTTPS redirect (3) enable UIR-FB-passive-mixed-content-only (4) enable
UIR-FB-all-mixed-content (5) enable CSP reporting to
https://report-uri.io or some similar service.

Currently we offer switches (1) and (2).  We'd like to flip (1) by default,
but cannot because it breaks HTTP images on some HTTPS pages that would
otherwise work fine (but trigger Chrome's triangle warning).  If (3) existed,
we could and would flip it safely as the default for Certbot users who ask for
security settings automation.

We still couldn't and wouldn't flip (2) by default.  And we wouldn't flip (4)
by default, but it would be nice to be able to offer it as a prominent
feature, especially in the form of a single switch that combines (2) (4) and
(5) together (conditional on the client UA being new enough to support (4)).



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

-- 
Peter Eckersley                            pde@eff.org
Chief Computer Scientist          Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

Received on Thursday, 7 July 2016 02:16:26 UTC