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

On Fri, Jul 01, 2016 at 04:30:00PM +0000, Brad Hill wrote:
> I do think this is interesting but I still think that the wide prevalence
> of and bad outcomes with active mixed content are still such that I'm not
> optimistic that a tool like Certbot can actually turn this on automatically
> for sites without creating serious breakage.  (unless we introduce a third
> state as proposed and for reasons discussed here
> http://webappsec-test.info/~bhill2/DifferentTakeOnOE.html)

Brad, that's a great writeup of the problem.

One of the key points I think is this:

   To make matters even worse, it is not trivial to even determine if your
   dependencies are ready! Once you go HTTPS, errors will just start happening
   for your users, and you have no obvious way to catch them in advance. (A
   "default-src https:" Content Security Policy directive can tell you
   when things actually broke, but you can't easily compose it with an
   optimistic upgrade to test without actual breakage.)
 
Probably one of the best arguments for a strong fallback mode for UIR (ie, one
that allows active mixed content to fallback, with appropriate UI degradation)
is that it will allow sites to deploy CSP in report-only mode to safely and
reliably detect mixed content problems.


> Assume we move forward with HSTS Priming, what is the expected incremental
> benefit here?  Is there a guess or telemetry on how many sites have only
> passive mixed content dependencies?  (remember if you have any critical
> scripts that aren't served over https, you can't send visitors to the https
> version of your site without breakage)

> 
> 
> -Brad
> 
> On Thu, Jun 30, 2016 at 4:18 PM Tanvi Vyas <tanvi@mozilla.com> wrote:
> 
> > pinging this thread to see if there are others that would be interested
> > in a fallback mode for upgrade-insecure-requests. Thanks!
> >
> > On 6/2/16 4:29 PM, Peter Eckersley wrote:
> > > On Wed, Jun 01, 2016 at 02:56:42PM -0700, Tanvi Vyas wrote:
> > >> upgrade-insecure-requests is a great way for sites to upgrade their
> > >> subresources to https without having to change hardcoded http links.
> > >> upgrade-insecure-requests provides a guarantee that no mixed content
> > will
> > >> load and degrade the security UI of a site.  In cases where an http
> > >> subresource cannot be loaded over https, the subresource will simply
> > fail to
> > >> load and any functionality that it provided will be broken.  Some sites
> > may
> > >> appreciate this property and want assurances that third party content
> > can't
> > >> degrade the security of their site.  Others may feel that they can't
> > afford
> > >> to have potentially broken functionality.  Or they may know of a single,
> > >> important subresource that isn't available over https and not want to
> > spend
> > >> the time and effort to upgrade the rest of their http links to https.
> > This
> > >> would prevent those sites from using upgrade-insecure-requests.
> > >>
> > >> I propose we add an upgrade-insecure-request-with-fallback option for
> > sites
> > >> and services that can't afford to break functionality but want the
> > potential
> > >> for increased security.  This fallback option can be either a separate
> > >> directive or an attribute on upgrade-insecure-request.  We will have to
> > be
> > >> careful to ensure that we don't break backwards compatibility with sites
> > >> that already set upgrade-insecure-requests and expect it not to
> > fallback.
> > >> Sites and services that opt into upgrade-insecure-request-with-fallback
> > >> should be aware that they may have slightly decreased performance,
> > because
> > >> in the fallback case there will be two roundtrips for the same
> > subresource.
> > > There are really two versions of the above that could make sense.  One is
> > > fallback for all subresources; the other is fallback for passive mixed
> > content
> > > only.
> > >
> > > I think it would be a huge win to offer fallback for passive mixed
> > content as
> > > a UIR variant, and it's something we've really been wanting for Certbot.
> > > Fallback for active mixed content might also make sense (as a separate
> > > directive from servers) and be a win but I expect we'll have to talk a
> > lot
> > > more about how to ensure that doesn't become a source of security holes,
> > and
> > > what the UI would look like.
> > >
> > > The case for passive mixed content fallback is simple: if
> > > upgrade-insecure-requests works in that mode, then it is unambiguously
> > > non-breaking to turn it on.  At present, upgrade-insecure-requests
> > unbreaks
> > > some script mixed content, and improves the security of some image loads,
> > > while also breaking some other image loads.  As a result, it can only be
> > set
> > > if a careful site-specific analysis of the consequences has been made.
> > If a
> > > passive-mixed-fallback mode existed, we would likely start setting it
> > for the
> > > ~100,000 domains that currently use Certbot with an installer and
> > request help
> > > in redirecting traffic from HTTP to HTTPS.  I suspect this might also be
> > of
> > > use to platforms like Cloudflare or Wordpress.com that are trying to
> > HTTPSify
> > > millions of domains where they don't fully control the underlying web
> > > application or HTML.
> > >
> > > The case for an active-content fallback seems more subtle: we know that
> > mixed
> > > content blocking has made HTTPS much harder to deploy, and there are
> > *some*
> > > sites where we'd probably rather have an imperfect deployment for content
> > > confidentiality vs surveillaince, than no deployment at all. This
> > stronger
> > > form of fallback is pretty comparable to the "opportunistic encryption"
> > > proposals that have been discussed at length, and would have to come with
> > > strong incentives to make it a temporary arrangement. Those could
> > include some
> > > visible UI degradation, an instant F grade on Qualy's SSL Labs
> > scorecard. Or
> > > something more creative, like a requirement that CSP report-only mode for
> > > mixed content be enabled at the same time, so the site has to learn
> > about how
> > > to start fixing its mixed content before enabling this comparatively
> > insecure
> > > option.
> > >
> >
> >
> >

-- 
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:04:01 UTC