Closed Bug 1231203 Opened 4 years ago Closed 2 years ago

investigate OCSP requests causing disk writes in private browsing mode

Categories

(Core :: Security: PSM, defect, P1)

defect

Tracking

()

VERIFIED FIXED
mozilla60
Tracking Status
firefox45 --- wontfix
firefox-esr52 --- wontfix
firefox58 --- wontfix
firefox59 --- verified
firefox60 --- verified

People

(Reporter: keeler, Assigned: keeler)

References

()

Details

(Keywords: privacy, Whiteboard: [psm-assigned][fingerprinting])

Attachments

(1 file)

A recent paper [0] from Georgia Institute of Technology has found that OCSP requests cause writes to the network cache even in private browsing mode. We should investigate this.

[0] http://wenke.gtisc.gatech.edu/papers/ucognito.pdf
Whiteboard: [psm-backlog]
Priority: -- → P3
Duplicate of this bug: 1436397
Assignee: nobody → dkeeler
Priority: P3 → P1
Whiteboard: [psm-backlog] → [psm-assigned]
Comment on attachment 8949836 [details]
bug 1231203 - ensure OCSP responses to requests from private contexts aren't cached on disk

https://reviewboard.mozilla.org/r/219152/#review224954

Code and test look good. Please revise the comment before landing, though.

::: security/manager/ssl/nsNSSCallbacks.cpp:122
(Diff revision 1)
>      priorityChannel->AdjustPriority(nsISupportsPriority::PRIORITY_HIGHEST);
>  
>    chan->SetLoadFlags(nsIRequest::LOAD_ANONYMOUS |
>                       nsIChannel::LOAD_BYPASS_SERVICE_WORKER);
>  
> -  // For OCSP requests, only the first party domain aspect of origin attributes
> +  // For OCSP requests, the first party domain and private browsing id aspects

This comment is a bit opaque, particularly deciding what "shared across containers" means when we're adding more origin attributes. Does this mean that OCSP cache entries are only shared if (the first party domain is the same), and also (if the private browsing flag is the same)?
Attachment #8949836 - Flags: review?(jjones) → review+
Comment on attachment 8949836 [details]
bug 1231203 - ensure OCSP responses to requests from private contexts aren't cached on disk

https://reviewboard.mozilla.org/r/219152/#review224954

Thanks!

> This comment is a bit opaque, particularly deciding what "shared across containers" means when we're adding more origin attributes. Does this mean that OCSP cache entries are only shared if (the first party domain is the same), and also (if the private browsing flag is the same)?

Ok - clarified.
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/06f87ee5bbbb
ensure OCSP responses to requests from private contexts aren't cached on disk r=jcj
Keywords: privacy
Hmmm... still investigating why this is failing...
Flags: needinfo?(dkeeler)
So those specific failures were due to me not setting the ocsp pref for android (where the default is different). However, there probably would have been intermittent failures anyway, since I wasn't quite using the cache correctly.
Here's a try run after those fixes: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1c6530be9fed
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ee10aee44d26
ensure OCSP responses to requests from private contexts aren't cached on disk r=jcj
https://hg.mozilla.org/mozilla-central/rev/ee10aee44d26
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Comment on attachment 8949836 [details]
bug 1231203 - ensure OCSP responses to requests from private contexts aren't cached on disk

This affects all current branches, but I'm not sure how far we want to uplift it, so I'm just starting with a beta request.

Approval Request Comment
[Feature/Bug causing the regression]: long standing bug
[User impact if declined]: OCSP requests from private browsing sessions (generated during certificate verification) can be cached on disk, leaking some information
[Is this code covered by automated tests?]: yes
[Has the fix been verified in Nightly?]: no
[Needs manual test from QE? If yes, steps to reproduce]: probably a good idea. str:

1. open Firefox, navigate to about:blank, clear all history
2. verify that the location indicated by "Storage disk location" under "disk" in about:cache is empty (this can be a bit finicky if the browser is making background requests - try clearing all history again)
3. open a private browsing window and go to e.g. https://bankofamerica.com
4. when that has loaded, verify that the disk cache directory is still empty

[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: not very
[Why is the change risky/not risky?]: the actual code change is very minimal
[String changes made/needed]: none
Attachment #8949836 - Flags: approval-mozilla-beta?
Comment on attachment 8949836 [details]
bug 1231203 - ensure OCSP responses to requests from private contexts aren't cached on disk

Fixing this seems like a good idea, includes new automated tests (yay!), Beta59+
Attachment #8949836 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Hi David, Dan, Ryan, since ESR52 is affected and this fix will be included in 59, I see no harm in uplifting to ESR52.7. Please let me know if you disagree. Thanks!
Flags: needinfo?(dveditz)
Flags: needinfo?(dkeeler)
Unfortunately, it looks like the interfaces I'm using in the test aren't available on esr52, so this would basically not have a test if we uplifted to esr52. We could manually verify - not sure if that's sufficient.
Flags: needinfo?(dkeeler)
Reproduced using Firefox 58.
Verified as fixed with Firefox 59 beta 10 and latest Nightly 60.0a1 under Win 10 64-bit, Ubuntu 14.04032-bit and Mac OS X 10.13.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
I'm fine with uplifting this to ESR-52 and relying on manual testing.
Flags: needinfo?(dveditz)
Whiteboard: [psm-assigned] → [psm-assigned][fingerprinting]
Well, at this point I'm not really sure it's worth it.
You need to log in before you can comment on or make changes to this bug.