Re: Intent to Implement- Double-keyed HTTP cache

2019-11-13 Thread Anne van Kesteren
On Wed, Aug 21, 2019 at 7:40 PM Sebastian Streich  wrote:
> Estimated or target release: Firefox 70

The plan is to enable this on Firefox 72 Nightly to see if there's any
fallout that needs addressing. It will not ride the trains. This is
tracked by https://bugzilla.mozilla.org/show_bug.cgi?id=1594004.

As network caches in general are a privacy and security concern, we're
tracking isolating all of them using the top-level origin in
https://bugzilla.mozilla.org/show_bug.cgi?id=1590107. If there are
further caches that could use such isolation, please do file a bug
blocking that bug.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement- Double-keyed HTTP cache

2019-08-22 Thread dom
On Thursday, August 22, 2019 at 11:26:55 AM UTC+9, Martin Thomson wrote:
> Hi Sebastian,
> 
> I'm glad to see us moving toward having better isolation in this way.
> 
> In discussions of this sort of keying strategy, the guidance I repeatedly
> hear is that "double-keying" isn't sufficient and that you need to key on
> the chain of origins.  That is, if A frames B and C, and B in turn also
> frames C, then the two C frames are isolated from each other in the same
> way that they are isolated from a top-level C.
> 
> I took a look at both the fetch issue and your patch and it wasn't clear
> what strategy we're using.  As an aside, an issue on a repo isn't really a
> specification.  I couldn't find a PR on fetch either.

For what its worth, browsers are also discussing what changes will need to be 
made for certain requests (like prefetch) in a double-keyed world. See [1], and 
the associated HTML Standard PR [2]. But you're right, there doesn't seem to be 
a real spec change at the moment for double-keyed cache itself from what I know.

]1]: https://github.com/w3c/resource-hints/issues/82
[2]: https://github.com/whatwg/html/pull/4115
> 
> What is the tuple we're keying on?
> 
> Cheers,
> Martin
> 
> On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich 
> wrote:
> 
> > Intent to Implement- Double-keyed HTTP cache
> >
> >
> > Summary:
> >
> > Currently Browsers are vulnerable to cache-timing attacks, commonly
> > referred to as XS Leaks attacks. Starting with Firefox 70 we want to
> > explore a double-keyed HTTP cache. Instead of solely using the origin of
> > the resource, we will double key the HTTP Cache using the top-level origin.
> > Using the top-level origin as the 2nd Key in the HTTP Cache allows to
> > counterfeit XS Leaks and eliminates the ability of checking cache contents
> > across Origins.
> >
> > Bug:  Bugzilla 1536058
> > 
> >
> > Standard: https://github.com/whatwg/fetch/issues/904
> >
> > Platform coverage: all platforms
> >
> > Estimated or target release: Firefox 70
> >
> > Preference: The feature will be pref'd behind
> > “browser.cache.cache_isolation”
> >
> >  and disabled by default.
> >
> > Other browsers:
> >
> > webkit: shipped
> >
> > Chrome :
> > implementing
> >
> > web-platform-tests: 
> >
> > Secure contexts:  This feature isn’t restricted to Secure Contexts.
> > Estimated or target release: Firefox 70
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement- Double-keyed HTTP cache

2019-08-22 Thread Anne van Kesteren
On Thu, Aug 22, 2019 at 4:26 AM Martin Thomson  wrote:
> What is the tuple we're keying on?

Top-level origin only. This still allows C to attack B in your
scenario (or vice versa). There's a variety of other side channel
attacks on " sites" too, including various members of the
Window object, history.length, and clickjacking. It would also allow B
or C to attack A, though there's a number of other things possible
there too.

I definitely think it's worth figuring out how we can enable "
sites" to better protect themselves as well as figuring out how to
improve sandboxing of " sites", but it would require a broader
effort than caches I think. I think isolating by top-level origin is a
huge improvement over the status quo and stops a fair number of
practical attacks against major sites (modulo popup attacks, see
Cross-Origin-Opener-Policy for that). (Many of which you can't frame
to be clear, due to X-Frame-Options.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Intent to Implement- Double-keyed HTTP cache

2019-08-21 Thread Martin Thomson
Hi Sebastian,

I'm glad to see us moving toward having better isolation in this way.

In discussions of this sort of keying strategy, the guidance I repeatedly
hear is that "double-keying" isn't sufficient and that you need to key on
the chain of origins.  That is, if A frames B and C, and B in turn also
frames C, then the two C frames are isolated from each other in the same
way that they are isolated from a top-level C.

I took a look at both the fetch issue and your patch and it wasn't clear
what strategy we're using.  As an aside, an issue on a repo isn't really a
specification.  I couldn't find a PR on fetch either.

What is the tuple we're keying on?

Cheers,
Martin

On Thu, Aug 22, 2019 at 3:40 AM Sebastian Streich 
wrote:

> Intent to Implement- Double-keyed HTTP cache
>
>
> Summary:
>
> Currently Browsers are vulnerable to cache-timing attacks, commonly
> referred to as XS Leaks attacks. Starting with Firefox 70 we want to
> explore a double-keyed HTTP cache. Instead of solely using the origin of
> the resource, we will double key the HTTP Cache using the top-level origin.
> Using the top-level origin as the 2nd Key in the HTTP Cache allows to
> counterfeit XS Leaks and eliminates the ability of checking cache contents
> across Origins.
>
> Bug:  Bugzilla 1536058
> 
>
> Standard: https://github.com/whatwg/fetch/issues/904
>
> Platform coverage: all platforms
>
> Estimated or target release: Firefox 70
>
> Preference: The feature will be pref'd behind
> “browser.cache.cache_isolation”
>
>  and disabled by default.
>
> Other browsers:
>
> webkit: shipped
>
> Chrome :
> implementing
>
> web-platform-tests: 
>
> Secure contexts:  This feature isn’t restricted to Secure Contexts.
> Estimated or target release: Firefox 70
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform