- From: Tanvi Vyas <tanvi@mozilla.com>
- Date: Tue, 10 Feb 2015 11:16:15 -0800
- 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