Opened 8 years ago

Closed 8 years ago

#3508 closed enhancement (fixed)

Apply new SafeCache patch

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: MikePerryIterationFires20110630
Cc: Actual Points: 3
Parent ID: Points: 3
Reviewer: Sponsor:

Description

One of Dan Boneh's students just upgraded SafeCache to Firefox 4. He also implemented a headers-only version of the double-key cookie policy: http://crypto.stanford.edu/cs294s/projects/browser.html

While the cookie bits don't seem to be that great (lots more side effects compared to Dan Witte's policy), the SafeCache definitely seems useful. I should merge them both in and just disable the cookie bits via pref.

Child Tickets

Change History (1)

comment:1 Changed 8 years ago by mikeperry

Actual Points: 3
Points: 3
Resolution: fixed
Status: newclosed

This ended up being a little tricky. We had to add some new prefs, remove the ones there, and change the default behavior a bit.

The result is that the cache restrictions are no longer tied to the cookie policy. 3rd party elements are given a cache key that binds them to the url bar domain. The original code by Collin Jackson binded elements to the domain in the referer, but this ended up producing some odd properties that seem non-ideal and yield no real security gain against cooperating adversaries.

As a result, Collin's test cases on the SafeCache test site won't function as expected. The test to verify functionality is to ensure that you get a different random ID whenver you actually load one of those iframes as either a top-level page or from another origin. This test works with 1.4.0.

The cookie restrictions are disabled. We need an implementation that applies to JS cookies as well for us to bother, I think.

Note: See TracTickets for help on using tickets.