Re: Intent to Implement- Double-keyed HTTP cache
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
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 > > <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugs.chromium.org/p/chromium/issues/detail?id=910708>: > > 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
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
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 > <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugs.chromium.org/p/chromium/issues/detail?id=910708>: > 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
Intent to Implement- Double-keyed HTTP cache
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 <https://bugzilla.mozilla.org/show_bug.cgi?id=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 <https://bugs.chromium.org/p/chromium/issues/detail?id=910708>: 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
