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

Re: CfC: Mixed Content to PR; deadline July 6th.

From: Brian Smith <brian@briansmith.org>
Date: Wed, 5 Aug 2015 13:23:17 -0400
Message-ID: <CAFewVt5KDLO1w2dUqHMwX_DQnS8bkCVJQ1WMD+DJr7PPzrUSBg@mail.gmail.com>
To: Mike West <mkwst@google.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Brad Hill <hillbrad@gmail.com>, Wendy Seltzer <wseltzer@w3.org>, Dan Veditz <dveditz@mozilla.com>, Kristijan Burnik <burnik@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Alex Russell <slightlyoff@google.com>, Ryan Sleevi <sleevi@google.com>
On Thu, Jul 30, 2015 at 3:59 AM, Mike West <mkwst@google.com> wrote:

> On Tue, Jul 28, 2015 at 7:24 PM, Brian Smith <brian@briansmith.org> wrote:
>
>> The thing that people working on service workers are most concerned about
>> is that adding a no-op service worker to a page should not break the page
>> even if it has mixed content. Allowing service workers to use the cache API
>> for non-secure documents goes beyond that and IMO adds unnecessary
>> complexity. it would be simpler and thus better to just not allow a service
>> worker to cache http:// responses.
>>
>
> What's the threat model that that would satisfy? Basically, it seems like
> the fetch is the hard thing to allow; once we've allowed the insecure
> fetch, caching the (opaque) result locally seems like a no-op. In the worst
> case, the same data is used later to satisfy a later (also insecure)
> request. In the best case, we avoid touching the network again in an
> insecure manner.
>

Well, for one thing, it is still very unclear (to me, at least) how
non-secure resources cached using the Cache API work. It seems to me like
they're not fully considered in the relevant specifications. In particular,
I want to ensure there is no risk that an http:// cached response can be
returns for an https:// request. And, I'd generally prefer to reduce
complexity by just not supporting http:// cached responses at all, so as to
reduce the likelihood of implementation flaws regarding them.


> Fewer plaintext requests seems like a security win that we should allow if
> we agree that allowing passthrough requests is reasonable.
>
>
>> In particular, it is unclear to me what prevents a service worker from
>> returning a response retrieved over http:// in response to an https://
>> request. Is that specified in the service workers spec, the fetch spec, or
>> this spec? Where in which spec?
>>
>
> That's in the service worker spec, specifically
> https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-response.
>
> Anne: I'm not sure what you meant by "I suppose it won't always disallow
> that". When would we want to allow insecure responses to secure requests? I
> don't think that's something we've discussed, nor is it something I think
> is terribly appealing.
>

I think the issue is that MIX and other things are written in a way that
allow a UA to give the user to unblock blockable mixed content. In that
case, based on my reading of what you linked to above, an http:// response
could be returned for an https:// request. But, that is wrong; an http://
response should NEVER be returned for an https:// request, even if the user
has disabled the browser's mixed content blocker.

Cheers,
Brian
Received on Wednesday, 5 August 2015 17:23:47 UTC

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