OCSP partitioning test site?

So I was testing out ETP Strict before migrating from FPI to dFPI, and something in about:networking#dns caught me off guard. For example, the isolation keys for github.com inside a container were github.com^userContextId=1&firstPartyDomain=%28https%2Cgithub.com%29&partitionKey=%28https%2Cgithub.com%29 and ocsp.digicert.com^firstPartyDomain=%28https%2Cgithub.com%29 when both privacy.firstparty.isolate and privacy.partition.network_state were true. When I disable FPI and switch to ETP Strict, only github.com^userContextId=1&partitionKey=%28https%2Cgithub.com%29 was shown but nothing for the OCSP cache (i.e. no ocsp.digicert.com^partitionKey=%28https%2Cgithub.com%29).

On the other hand, the isolation keys for Google Safebrowsing and its OCSP were always safebrowsing.googleapis.com^firstPartyDomain=safebrowsing.[blah-blah-blah].mozilla and ocsp.pki.goog^firstPartyDomain=safebrowsing.[blah-blah-blah].mozilla, regardless of whether FPI or dFPI is active.

So I am not sure if this is just a about:networking thing and the OCSP cache is actually still being partitioned? Unlike cookies this does not seem to be easily verifiable on the client side.

[Jee-Hex]

I think I actually solved this a while ago but I haven’t come round to writing it up…

Well turns out news.ycombinator.com is “bypassing” OCSP responder servers because of OCSP stapling. And of course the OCSP staus response is per-site, so my test above was absolute BS. But long story short, yes it is just a about:networking#dns thingy; OCSP partitioning works and even when I turn off Tracking Protection.

Here’s my (new) test case anyway:

1. Confirm that privacy.partition.network_state is currently set to true and privacy.partition.network_state.ocsp_cache to 'false.
2. (For testing purposes) disable security.ssl.enable_ocsp_stapling because secure.gravatar.com uses OCSP stapling.
3. Block ocsp.sectigo.com at port 80 in your firewall/router.
4. Visit any bugzilla ticket (All gravatars should fail to load).
5. Now unblock ocsp.sectigo.com at your firewall/router.
6. Right-click on any gravatar and copy its image location.
7. Open the link in a new tab.
8. You should get a SEC_ERROR_OCSP_SERVER_ERROR response because OCSP cache is not partitioned.
9. Flip privacy.partition.network_state.ocsp_cache to true and restart Firefox.

Rinse and repeat, you should now be able to see the gravatar in a new tab. Soprivacy.partition.network_state.ocsp_cache does work and I am just going to blame mozilla devs for not updating about:networking#dns (sorry!).

[Thorin-Oakenpants]

closing … this will never be done (testing from our/my side) … I appreciate testing upstream code, and bugz happen, but this is just beyond my time and scope