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

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.
>

Received on Thursday, 30 June 2016 23:16:49 UTC