[UPGRADE] passive mixed content breakage with the current variant of upgrade-insecure-requests

Since Let's Encrypt has now launched, we've been starting to experiment
with automating enablement of security features.  Folks who use the
official python client's Apache cert installer plugin can add flags like
--hsts or --uir to get HSTS or upgrade-insecure-requests, and we're
considering making the latter default behaviour.

In the process of evaluating that, we've realised that the current spec
and implementations have issues with the way they treat passive mixed
content that makes upgrade-insecure-requests much harder to enable than
it should be.

This page has a number of different types of passive mixed content in an
https page:
 
https://isnot.org/mixed/

This variant is identical, but sends the upgrade-insecure-requests
header:

https://isnot.org/mixed-uir/

Chrome renders the first page fine, but upgrade-insecure-requests breaks
it.  That's also true on Firefox, though sometimes cached HTTP images
are used despite the upgrade-insecure-request header.

It's really bad for a feature that's intended to make HTTPS easier to
deploy to be causing breakage.  Probably the correct network behaviour
here is that the browser should *try* the upgraded versions of images
and other passive subresources, but fall back to the HTTP version if
HTTPS fails.

If anyone really wants the current behaviour (upgrade-insecure-requests
implies a guarantee that third party images are upgradeable) they should
in theory be able to get it back with an "img-src https://*" CSP
directive (though that seems to currently not work because CSP img-src
fires before upgrade-insecure-requests, see
https://isnot.org/mixed-uir-csp-imgsrc-https/ )

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

Received on Sunday, 27 December 2015 08:43:04 UTC