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

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

From: Mike West <mkwst@google.com>
Date: Thu, 30 Jul 2015 09:59:20 +0200
Message-ID: <CAKXHy=f+vEqDzQGdFe7Vcgvx3jpAOEz+WD3+3YBSVz4EDMiS8g@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
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 Tue, Jul 28, 2015 at 7:24 PM, Brian Smith <brian@briansmith.org> wrote:

> On Mon, Jul 20, 2015 at 9:39 AM, Mike West <mkwst@google.com> wrote:
>
>> Brian, note that this means we really do need the response checking bits
>> that you were concerned about earlier.
>>
>
> Is this because the fetch could return an http:// response that was
> stored using the cache API by a service worker that forwarded a fetch for
> an <img>, <video>, or <audio>?
>

Yes.


> Is there some other reason why response checking is needed due to allowing
> fetch to forward mixed content requests for those types of fetches?
>

No (though I'd of course note that the `deprecated` concept requires
response checking as well).

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.

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.

-mike

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Received on Thursday, 30 July 2015 08:00:13 UTC

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