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

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, 2 June 2016 23:29:54 UTC