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