Closed Bug 1670506 Opened 4 years ago Closed 3 years ago

OCSP requests shouldn't use the HTTP cache

Categories

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

defect

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: robwu, Assigned: keeler)

References

Details

(Whiteboard: [psm-assigned])

Attachments

(1 file)

/data/data/org.mozilla.focus/cache/hjh4ctfp.default/cache2/entries contains many entries that appear to be OCSP responses. Firefox Focus is not supposed to persist data, so this is a privacy issue.

Strangely, every OCSP response is duplicated (the content is almost identical). This duplication is not a regression, the cache has entries from 2019 (which is when I manually wiped the data of Firefox Focus).

File size, date, file name in /data/data/org.mozilla.focus/cache/hjh4ctfp.default/cache2/entries :

$ ls -lt $(grep -rl ocsp) | cut -c22- | head -n50
3012 Oct  9 11:21 10A28CB33EEDF8830702EEC0D57BB6A108551902
3012 Oct  9 11:21 CB8F6F5662E16B4F30AD4CED3F4168DA355180FE
2949 Oct  8 23:00 6AD0E0368DD9B0FA3690CE76884901EBEEE0660F
2949 Oct  8 23:00 F9FA7ED6D6DA95407242225C28223CD8C4114E37
2451 Oct  6 14:57 A6AD43BC28384ED916067E36DA7A1DCAE6B3BA5B
2451 Oct  6 14:57 E9C0C63631AC395A9BD570E778C7DFABAD82C207
2452 Oct  6 14:55 397A635D7FF5699ECAFE16A932B12026E6B10484
2452 Oct  6 14:55 AED75EAFB667A267C13511743578CE0BFE8CD4AE
1276 Sep 29 09:50 09F73514C50758A4E63F3D4C0692EFEFBA4272DC
1276 Sep 29 09:50 2FB0E1DE2975EB3628AC2EA0BCCE8448557B0A99
1276 Sep 29 09:50 44994928B7003516A8E6CB87E1627AAC95CD152A
1276 Sep 29 09:50 B32344DB3E157148CB8091F3D99A393B6182CDB0
1276 Sep 27 08:45 6ACAC73FFA3DF803E69C76B6211D5CDE53E5C27A
1276 Sep 27 08:45 A9F1ABE35A53D5711C5ED78F78BE15CEC95709CF
1276 Sep 27 08:45 EA39FFDB1E10D625EB4EA3059EDBA01F23901640
1276 Sep 27 08:45 F4DB5F3D8E997B905538BDDC387F9398AECE699C
2451 Sep 25 19:43 0A928A220A42C784A3EB3663D52C5EA0F8AE06E8
2451 Sep 25 19:43 2FB93CB16C9EE0B0141EF77C3BF456D7C7B1F16B
1276 Sep 21 09:40 0E93E32C0A7DAFAE4DE03A9757B571A472D43374
1276 Sep 21 09:40 3F13E7A728F8DEEE2E025409132C83F2881BB96B
1276 Sep 21 09:40 9E1EB4FFBAA1A52A158D9505ED4DEB92E4F11572
1276 Sep 21 09:40 B32FA639EE2B444DFBE64FFFFEA7352880FC0047
1274 Sep 13 22:07 44B44E6911B79F8E5682DA70BE01DB61B2FFB8BB
1274 Sep 13 22:07 4D0B63E9B4AA989CFE433D0B3C6A36220CEE8039
1276 Sep 13 22:07 7AE6BA77B6AF0E7D942D17317389119F5EE3FD03
1276 Sep 13 22:07 B449F5A0ECFEF6C46804D1ACCE4CB4BD71516ED4
1276 Sep 11 10:43 96758C3D4F83F96152C658465E0AC426155DF7D7
1276 Sep 11 10:43 B6675F4366794F98FA3950A3721CD408FC351CFE
2947 Sep 11 02:01 133E44832AFFC6938E3E76B133B6177639D2B2D0
3012 Sep 11 02:01 544F6FE2E53CE83BA8B79A29B80A3E30890C53CA
3012 Sep 11 02:01 6CF7A7CEE54B3AD8CB5BE6A840A2164DE94B0A3A
2947 Sep 11 02:01 EAA3890BEE1F86B4192EF17E93AA10A5DDDA0DAB
1276 Sep  8 08:31 4E3A49661498256ADCDF238C85B32FA0489FDEF3
1276 Sep  8 08:31 979867062E97CDEFC59A962AD8E7A8AC6540B8EE
2269 Sep  5 11:07 097F489C3AC7A986F26BDD8A90DDDFD4BBFFA442
2452 Sep  5 11:07 2B879D67129C55517991448EC89C87C7C377A3DD
1485 Sep  3 03:10 BDE9E41F2E78537B0D97E03ECCBA52A061FFEAFC
1743 Sep  3 03:10 CAB68AC508F02A8543EBD531280DD56E86273DBF
1743 Sep  3 03:10 EF37ABB48B2911B3F6B4B4E84F158E7248EE0584
1485 Sep  3 03:10 F023794712073DC61D28FA6BB0E3B3AA96F8ED06
2451 Sep  1 13:22 01400455CBB1D649CA6F0EEDD3099D8F22502E9A
2451 Sep  1 13:22 8359C267E78B07D66C9CCC52A423C9103EE241E7
2452 Sep  1 11:41 850D3EEF78FA4FE324203895D17DAC4248B38151
2452 Sep  1 11:41 99650FEF62CEC0A25E593D0CEEB2AE5BA5DF459E
2452 Sep  1 11:41 AF657552017977072E951DF380D3A346134A21DE
2452 Sep  1 11:41 AF7974CB8A821F9B1A258F373D7896B23AF2DC19
1276 Aug 28 15:06 0E45294C1202A4D50FFEE13F448D8DA1BCB03F3C
1276 Aug 28 15:06 238D45D925F6DD7ED3DF8EDA9A77C7FE0A7ED650
1276 Aug 28 15:06 D3D21F502CF3DBB0F5D7B0302E2C8F3BB03213EE
1276 Aug 28 15:06 F00C966C3DD5D8E739279961EFEAB3F88B6D7E55

Example of response for http://ocsp.entrust.net/ (from E9C0C63631AC395A9BD570E778C7DFABAD82C207).

Content-Type: application/ocsp-response
ETag: "BB6BF53BA25EA4AB8DFBCF7B73CCC1EF66F3F12131EA4C6B9FBF2C734B8D4C19"
Last-Modified: Tue, 06 Oct 2020 12:00:00 UTC
Content-Length: 1585
Cache-Control: public, no-transform, must-revalidate, max-age=3371
Expires: Tue, 06 Oct 2020 13:53:37 GMT
Date: Tue, 06 Oct 2020 12:57:26 GMT

mozilla::pkix is responsible for the OCSP cache, so moving to PSM, but this may be a situation where either Focus or the temporary profile system simply isn't calling OCSPCache::Clear when it should.

In any case, CRLite will fix this. :)

Assignee: nobody → nobody
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: jjones
Version: other → unspecified

The OCSP cache isn't saved to disk - this is necko caching. So either we need to change how PSM makes net requests or necko needs to do something different.
Here's where PSM makes the request: https://searchfox.org/mozilla-central/rev/61728de8273c04fe2417c475fc0637e8b79210d7/security/manager/ssl/nsNSSCallbacks.cpp#246
Dragana, is that code doing something that would cause these requests to be cached when they shouldn't be?

Flags: needinfo?(dd.mozilla)
Component: Security: PSM → Networking: Cache

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #2)

The OCSP cache isn't saved to disk - this is necko caching. So either we need to change how PSM makes net requests or necko needs to do something different.
Here's where PSM makes the request: https://searchfox.org/mozilla-central/rev/61728de8273c04fe2417c475fc0637e8b79210d7/security/manager/ssl/nsNSSCallbacks.cpp#246
Dragana, is that code doing something that would cause these requests to be cached when they shouldn't be?

That code is not doing anything special with cache, there is no special directives that would influence cache.

I do not know how how Focus disables cache, probably setting the browser.cache.disk.enable pref to false.
OCSP request above should not be treated any different to any other request.

Flags: needinfo?(dd.mozilla)

(In reply to Dragana Damjanovic [:dragana] from comment #3)

I do not know how how Focus disables cache, probably setting the browser.cache.disk.enable pref to false.
OCSP request above should not be treated any different to any other request.

Rob?

Flags: needinfo?(rob)

(In reply to Dragana Damjanovic [:dragana] from comment #3)

I do not know how how Focus disables cache

"Focus uses private mode, so no data is stored" according to https://github.com/mozilla-mobile/focus-android/issues/3344#issuecomment-419447370 ,

And indeed:

... and when I open any web page in Firefox Focus on Android, enable remote debugging, visit about:debugging on desktop to connect to it, and run browser.loadContext.originAttributes.privateBrowsingId, then I can indeed see that it's 1. Is it possible that there are other kinds of requests that don't use private browsing mode that fills the cache? E.g. favicons?

Flags: needinfo?(rob)

(In reply to Rob Wu [:robwu] from comment #5)

(In reply to Dragana Damjanovic [:dragana] from comment #3)

I do not know how how Focus disables cache

"Focus uses private mode, so no data is stored" according to https://github.com/mozilla-mobile/focus-android/issues/3344#issuecomment-419447370 ,

And indeed:

... and when I open any web page in Firefox Focus on Android, enable remote debugging, visit about:debugging on desktop to connect to it, and run browser.loadContext.originAttributes.privateBrowsingId, then I can indeed see that it's 1. Is it possible that there are other kinds of requests that don't use private browsing mode that fills the cache? E.g. favicons?

favicons should inherit the flag from the top page load, probably, there are other internal requests that will not have that flag set. I would recommend to set setting browser.cache.disk.enable pref as well.

Kevin, I want to raise this issue to the Focus engineers (particularly the suggestion quoted below).
I cannot see "Focus" in the list of Products to choose from in Bugzilla, hence the needinfo. Could you triage this bug?

(In reply to Dragana Damjanovic [:dragana] from comment #6)

favicons should inherit the flag from the top page load, probably, there are other internal requests that will not have that flag set. I would recommend to set setting browser.cache.disk.enable pref as well.

Flags: needinfo?(kbrosnan)

Would this be handled by moving to the AC browser components?

Flags: needinfo?(kbrosnan) → needinfo?(s.kaspari)

To my knowledge we do not use Gecko (through GeckoWebExecutor) for any requests in Focus so far. However we have been using HttpUrlConnection and OkHttp for some requests (e.g. search suggestions). Last week we migrated those over to using Gecko and will make sure we set the flags correctly (I filed #4764 to verify that). But from the file path we are sure it's a cache created by us, right?

Flags: needinfo?(s.kaspari)

(In reply to Dana Keeler (she/her) (use needinfo) (:keeler for reviews) from comment #2)

The OCSP cache isn't saved to disk - this is necko caching. So either we need to change how PSM makes net requests or necko needs to do something different.
Here's where PSM makes the request: https://searchfox.org/mozilla-central/rev/61728de8273c04fe2417c475fc0637e8b79210d7/security/manager/ssl/nsNSSCallbacks.cpp#246
Dragana, is that code doing something that would cause these requests to be cached when they shouldn't be?

I think this issue also affects desktop users in PB mode, where we shouldn't be saving anything persistently, right?
Technically we should be doing the right thing here - we set the originAttributes to the privateBrowsingId.

But sometimes it's possible we don't call UpdatePrivateBrowsing in AsyncOpen.

@Dana: is the HTTP cache useful at all for the OCSP checks? It is possible to set the load flags to:
INHIBIT_PERSISTENT_CACHING - only saves to the memory cache, never to disk
INHIBIT_CACHING - don't cache the response at all, either memory or disk
LOAD_BYPASS_CACHE - not attempt to load responses from the cache

We can also set them specifically when in PB. Or we could specifically call nsIPrivateBrowsingChannel.SetPrivate on the channel to make sure it is treated as a PB channel.

This is in addition to calling UpdatePrivateBrowsing() unconditionally in AsyncOpen, which is possibly a bug.

Flags: needinfo?(dkeeler)

Yeah, I think it doesn't make sense to use the HTTP cache for OCSP at all, so I'll go ahead and make that change.
I do feel like there is still a bug specific to private browsing, but it won't matter to this code after making that change.

Assignee: nobody → dkeeler
Severity: -- → S2
Component: Networking: Cache → Security: PSM
Flags: needinfo?(dkeeler)
Priority: -- → P1
Summary: OCSP responses saved in disk cache in Firefox Focus → OCSP requests shouldn't use the HTTP cache
Whiteboard: [psm-assigned]
Pushed by dkeeler@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5c788299df1e
OCSP requests shouldn't interact with the necko cache at all r=valentin
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: