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

On Tue, Jul 12, 2016 at 08:42:42PM +0000, Brad Hill wrote:
> I understand the value; I guess I would leave it up to UA implementers.  We
> currently have implementations in Chrome, Firefox and Safari.  Would those
> implementers be interested in adding a mode with fallback?  On what
> timeline?  Should we try to do this before moving Upgrade Insecure Requests
> to Proposed Recommendation?

I'm curious to hear Tanvi and Mike's thoughts on this (not sure who worked on
the Safari implementation), but just personally I think it would be a mistake
to proceed further with a version of the UIR spec that's a double-edged sword
for site operators. I think we need to have a version of it that strictly
helps to mitigate mixed content situations without making some of them
worse.

Mike, if it were helpful, I'd be happy to draft a spec PR for this.

> 
> On Wed, Jul 6, 2016 at 7:15 PM Peter Eckersley <pde@eff.org> wrote:
> 
> > 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
> >

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

Received on Tuesday, 12 July 2016 23:44:19 UTC