RE: Comments on Mixed Content

Hi,

Thanks for your patient, given my newbie status in this area, it took a while to get the feedback from those with deep expertise.

Merged Chris and Anne comments inline with Mike's.

There are no new topics, this response is just trying to close down the topics that had I already opened.

Cheers,
_dave_

> From: Mike West [mailto:mkwst@google.com] 
> Sent: Thursday, December 11, 2014 3:52 AM
> To: David Walp; Anne van Kesteren
> Cc: public-webappsec@w3.org
> Subject: Re: Comments on Mixed Content
>
> Thanks for the feedback, David! I'll address the individual points inline.
>
> On Wed, Dec 10, 2014 at 2:32 PM, David Walp <David.Walp@microsoft.com> wrote:
>
>> 1) Section 2.2, TLS-protected & Weakly TLS-protected (and throughout the spec).
>> There appears to be an assumption the only environment is the internet and that intranet environments are not addressed.   We think this would be addressed by
>>  adding wording in section 2.2 that stated User agents are free to interpret protection with in a trusted environment.

> On Wednesday, December 10, 2014 4:44 PM, Chris Palmer <palmer@google.com> wrote:
>
> How should a UA programmatically and unambiguously determine that the page's origin is served from an intranet server?
> What about passive and active attackers on the intranet?
> 
> Why create ambiguity in the user's overall browsing experience?
> 
> Why create an affordance for not fixing mixed content bugs?

> I share Chris' skepticism of such wording. The NSA's infamous "SSL added and removed here" slide should make it quite clear that intranets are a) targets, and b) not as > secure as we'd all like them to be.
> 
> Additionally, intranets are free to use insecure transport if they choose to. `http://intranet/` would not trigger mixed content warnings (and would also be clearly
> insecure). If an intranet chooses to use secure transport, we should not reduce their expectations of security based simply upon hostname or IP address.

Given that not all browser are able to distinguish between Intranet and Internet, unless we hear otherwise we will assume this specification is specific to the Internet environment.  OK?
 
> 2) Section 3.2, "Plugin data" in bulleted list.
> Our assumption is blocking (or not blocking) of the plugin data is the responsibility of the plugin.   Correct?
>
> That likely depends on the implementation. In Chrome, the PPAPI version of Flash sends at least most of its traffic through Chrome's network stack, which means we
> can make some progress in terms of blocking mixed requests without relying on the plugin to do so for us.
>
> It's entirely possible that other implementations will need to rely on the plugin itself to do blocking (as Chrome and other UAs do with Flash and Incognito mode today).
 
Because it is difficult (at least for us ) to understand what a plugin is doing, we have to rely on the plugin to do the right thing.  Our proposed tact would be users are responsible for the plugins installed and user agents should not be considered out of compliance because of user installed plugins. Sound OK?

> 3) Section 3.2, "cspreport" in sentence starting with "These resource types map to the following Fetch request contexts:".
> Our concern is that using cspreport is a valid method to find mix content.  Is there another specified method to find mix content?

> CSP is a great way to discover mixed content! However, this document requires that your CSP endpoint must be secure if the page generating reports is secure. This
> seems like a reasonable restriction to ensure the privacy properties of HTTPS are kept intact.

Agreed.

> 4) Section 4.1,  twice there is the text "return a synthetically generated network error response".
> The statement " return a synthetically generated network error response" doesn’t reflect the goal of the requirement to us.  We think the statement is related to the
> need to return network error to script on the web page because of mixed content.  Please can we get some clarification about the requirement behind this text.

> First, note that section 4 has been more or less dropped entirely in the latest editor's draft, in response to some of Brian Smith's feedback from a week or three ago.
> 
> Second, that phrase is pointing to Fetch's concept of a "network error" (see https://fetch.spec.whatwg.org/#concept-network-error). The goal is to ensure that the
> Fetch process doesn't return (or request!) actual data from the network, but instead pretends that a network error occurred, and deal with the request just as though > someone had yanked out your ethernet cable during the request. See step #4 of https://fetch.spec.whatwg.org/#fetching for details of how this works.
> 
> I think the intent is fairly straightforward, but I'm happy to consider suggestions for a phrasing that would be less confusing.

How about instead of "instead return a synthetically generated network error response" the wording "instead be treated as if a network or security error is returned."?

> 5) Section 4.1, list items #1 and #3. 
> Why is there an inconsistency in the error handing mechanism between #1 (XHR) and #3 (Websockets)?
> 
> WebSockets currently throw if the secure flag is false but the calling origin is secure (see step #2 of 
> http://www.w3.org/TR/2012/CR-websockets-20120920/#the-websocket-interface.

> 
> Anne (CC'd) convinced me that changing XHR to do the same would be a bad idea from a compatibility perspective. However, given that WebSockets is already 
> throwing, and has been for years, it seems reasonable to simply update it's language to match this specification and current concepts (note that "entry script" no longer > exists).

> On Thursday, December 11, 2014 4:09 AM, Anne van Kesteren annevankesteren@gmail.com
> 
> WebSocket is its own stack. XMLHttpRequest however builds on the same stuff <img>, <script>, background-image, <link rel=icon>, sendBeacon(), etc. build on, Fetch. > They should have consistent handling of this stuff and it should be in the network layer. We also don't want that each new API we introduce that builds on Fetch, e.g.
> fetch(), has to consider this and special case Mixed Content behavior.
> That's just very bad layering.

We think we are consistent between Websockets & XHR in our engine under development.  And we think our behavior is the same as Chrome.  Neither should throw an exception.

> 6) Section 5.1, Example 4.
> We would like to understand the rationale behind this example.  Given a.com is already unsecure, how is user to understand the iframe with b.com is different (aka 
> secure).

> I agree with you that the end-user can't be expected to understand or distinguish between portions of a page which are framed or native. I don't believe that user 
> expectations are the only expectations we need to care about.
>
> In particular, it seems unwise to allow a site's security properties to be changed based on the context in which it is loaded. If I serve a site over HTTPS, that ought to give > me certain expectations for behavior, and allow me to assume certain limitations.
>
> Consider, for example, a page on `b.com` which mistakenly attempts to load script from an insecure source. That script should be blocked, for `b.com`'s protection, 
> regardless of the page's ancestry.

Agree.

> 7) Section 5.1, Example 5 - "even though the framed data URL was not".
> We believe the text "even though the framed data URL was not" is incomplete.  Our opinion is that data URL should be treated the same as the web page that contains
> the data URL.

> `data:` URLs usually aren't delivered over a secure connection. Typically, they're (probably) synthesized by JavaScript and injected into a page. This could potentially
> even happen from a child frame (`window.parent.frames`) or from an ancillary browsing context (`window.opener.frames`).
> 
> In this case, there's no meaningful distinction: we treat the frame as secure if one or more of its ancestors is secure, and as insecure otherwise.
>
> How would you suggest that we change the phrasing of this example, assuming you agree with the conclusion that the insecure request to `http://evil.com/` ought to
> be blocked?

As a.com was loaded over a secure connection, the framed data URL inherited the secure context of its parent and hence loading from evil.com is blocked.  Make sense?

> 8) Sections 5.2  &  7 - What about legacy - XHR?.
> Sections 5.3 & 7 both address Fetch implementations but there are not similar sections for XHR.  Given the current wide adoption of XHR, why are similar sections about 
> XHR not needed?

> Fetch defines the mechanisms that XHR uses in order to go out to the network, grab data, and return it to the client. In other words, XHR is layered on top of Fetch, so 
> altering Fetch to support mixed content checks implicitly alters XHR as well.

Since our current implementation of XHR is not layered on Fetch, for now we'll need to trust your layering statement that XHR is a proper subset of Fetch.

Received on Tuesday, 13 January 2015 23:05:55 UTC