Update: W3C Web Application Security WG - first public working draft

Hi all,

Thought this would be an interesting topic to you all.

Sincerely,
Adam

Mixed Content First Public Working Draft
(http://www.w3.org/TR/2014/WD-mixed-content-20140722/)

W3C Web Application Security WG Charter: https://www.w3.org/2013/07/webappsec-charter.html

This spec is intended to alleviate two security and privacy risks related to content delivered over a secure channel, like https.  The first is when that securely retrieved page fetch's resources to use with it from a non-secure channel (e.g. script or css or images or other content from a non-secure channel).  The other is if the content from the secure channel gets content either from the local, non-public network (like 192.168.0.0/16) or the same device (like 127.0.0.1) or the local file system (like file: )

The spec differentiates between passive content like images or video that can't interact with or modify the page and active content like scripts or css that can.  Passive content is less dangerous but can be used to deceive the user.  Active content from a non-secure channel mixed with content from a secure channel is more dangerous.

The spec also distinguishes between blockable passive content like data from xhr or websockets and optionally blockable content like audio, video and images.  The difference is that a huge amount of the web depends on mixed content involving optionally blockable content. (so they can't really automatically block it without breaking a lot of the web).

Examples of some of the types of Browser (User Agent) requirements in the spec - to give a sense of what the spec is like:
- should reject weakly-protected tls resource requests unless specifically ask user if it's ok (e.g. https with self-signed server digital certificates)
- from a secure page, must synthesize network error for requests of active or blockable content from insecure channel
- from a secure page, should treat optionally blockable content from insecure channel the same as active - e.g. was there is a strict-transport-security header
- for optionally blockable content, may take actions like not pass cookies or authentication tokens
- from secure page, must through security exceptions if JavaScript tries to open connections on insecure channel with xhr, web events, websockets

Here is the introduction from the draft. This describes the problem to be solved, but not what the spec does.
+++ from http://www.w3.org/TR/2014/WD-mixed-content-20140722/#intro

Introduction
This section is not normative.
When a user successfully loads a resource from example.com over a secure channel (HTTPS, for example), the user agent is able to make three assertions critical to the user's security and privacy:
o    The user is communicating with a server that is allowed to claim to be example.com, and not one of the many, many servers through which her request has hopped. The connection can be authenticated.
o    The user's communications with example.com cannot be trivially eavesdropped upon by middlemen, because the requests she makes and the responses she receives are encrypted.
o    The user's communications with example.com cannot be trivially modified by middlemen, the encryption and authentication provide a guarantee of data integrity.
Together, these assertions give the user some assurance that example.com is the only entity that can read and respond to her requests (caveat: without shocking amounts of work) and that the bits she's receiving are indeed those that example.com actually sent.
The strength of these assertions is substantially weakened, however, when the encrypted and authenticated resource requests subresources (scripts, images, etc) over an insecure channel. Those resource requests result in a resource whose status is mixed, as insecure requests are wide open for man-in-the-middle attacks. This scenario is unfortunately quite common.
Regardless of example.com's own privacy, users' privacy and security can be further impacted if a public resource can generate requests to private resources on a local network. For example, public resources must not be allowed to generate requests to a user's router, or an enterprise's internal file server.
This specification details how user agents can mitigate these risks to security and privacy by limiting a resource's ability to inadvertently communicate in the clear, or to expose non-public resources to the web at large.
Note: Nothing described in this document is really new; everything covered here has appeared in one or more user agents over the years: Internet Explorer led the way, alerting users to mixed active content since at least version 4.
+++

Adam M Abramski
Product Planner
Intel Software & Services Group
503-264-8269 (o)
503-550-7910 (m)
adam.m.abramski@intel.com