W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

Re: CfC to publish FPWD of "Upgrade Insecure Resources"; Deadline Feb 17th.

From: Tanvi Vyas <tanvi@mozilla.com>
Date: Tue, 10 Feb 2015 11:16:15 -0800
Message-ID: <54DA58FF.5080900@mozilla.com>
To: Jim Manico <jim.manico@owasp.org>, Crispin Cowan <crispin@microsoft.com>
CC: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Brad Hill <hillbrad@gmail.com>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Peter Eckersley <pde@eff.org>, yan zhu <yan@mit.edu>
On 2/10/15 10:57 AM, Jim Manico wrote:
>> That there should be a “strict” mode e.g. for banks that want absolutely all traffic encrypted, and a “slack” mode e.g. for mashup web sites that want to encrypt all of their own content, but not that coming from some other web sites that they are pulling from.
>
> Slack makes no sense to me; if the adversarial observer on your
> network sees part of the page loaded via HTTP they can inject their
> own content and game over. You are either all HTTPS or not HTTPS,
> right?
What if the HTTP non-same origin data is optionally-blockable content?  
The same-origin content will get upgraded and mixed passive / 
optionally-blockable HTTP content from other origins will get loaded.  
The cookies associated with the origin won't get exposed since the 
same-origin requests have been updated and the content that is loaded 
can't use document.cookie.

Alternatively, instead of a strict and slack mode, we could have a mode 
that upgrades just blockable content.  We can do this my assigning a 
value to the directive
upgrade-insecure-requests: all                   // attempts to upgrade 
all mixed content
upgrade-insecure-requests: blockable        // attempts to upgrade 
blockable mixed content and loads optionally-blockable content without 
an attempt to upgrade
upgrade-insecure-requests                        // attempts to upgrade 
all mixed content

Just depends on how granular and how complicated we want to make the 
directive.

~Tanvi
Received on Tuesday, 10 February 2015 19:16:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC