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

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?

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
>