ensure OCSP requests respect URL bar domain isolation
Following #5752 (moved), all web content for a page is requested on a circuit devoted to the page's URL bar domain. OCSP requests, however, are being incorrectly sent on a separate circuit. Favicons and DNS queries, etc, should also be checked for violations.
Probably we need to fix ThirdPartyUtil::GetFirstPartyUri to return the parent page's domain for OCSP requests.
See also #9783 (moved).
Activity
Trac:
Description: Following #5752 (moved), all web content for a page is requested on a circuit devoted to the page's URL bar domain. OCSP requests, however, are being sent on a separate circuit. Favicons and DNS queries, etc, should also be checked for violations.Probably we need to fix ThirdPartyUtil::GetFirstPartyUri to return the parent page's domain for OCSP requests.
See also #9783 (moved).
to
Following #5752 (moved), all web content for a page is requested on a circuit devoted to the page's URL bar domain. OCSP requests, however, are being incorrectly sent on a separate circuit. Favicons and DNS queries, etc, should also be checked for violations.
Probably we need to fix ThirdPartyUtil::GetFirstPartyUri to return the parent page's domain for OCSP requests.
See also #9783 (moved).
Here's another possibly dangerous connection: getFirstPartyURI failed for https://addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/31.4.0/Firefox/20000101000000/Darwin_x86_64-gcc3/en-US/alpha/Darwin%2013.4.0/default/default/1/34/15/: 0x80070057
Here's my patch for favicons: https://github.com/arthuredelstein/tor-browser/commit/0e02e34fbf4a5474dff6b5dedad6cde2b785febe
Here are my two patches for this ticket. The second patch (13670.2) needs the first patch (13670.1) applied to work. https://github.com/arthuredelstein/tor-browser/commits/13670+7
Trac:
Keywords: TorBrowserTeam201503 deleted, TorBrowserTeam201503R added
Status: assigned to needs_review
/home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp: In member function 'SECStatus mozilla::psm::OCSPCache::Put(const CERTCertificate*, const CERTCertificate*, const char*, PRErrorCode, PRTime, PRTime)': /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:205:56: error: no matching function for call to 'mozilla::psm::OCSPCache::FindInternal(const CERTCertificate*&, const CERTCertificate*&, mozilla::MutexAutoLock&)' int32_t index = FindInternal(aCert, aIssuerCert, lock); ^ /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:205:56: note: candidate is: /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:117:1: note: int32_t mozilla::psm::OCSPCache::FindInternal(const CERTCertificate*, const CERTCertificate*, const char*, const MutexAutoLock&) OCSPCache::FindInternal(const CERTCertificate* aCert, ^ /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:117:1: note: candidate expects 4 arguments, 3 provided make[5]: *** [OCSPCache.o] Error 1Let's see how it goes if I add the missing
aIsolationKey.Trac:
Status: needs_review to needs_revisionReplying to gk:
{{{ /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp: In member function 'SECStatus mozilla::psm::OCSPCache::Put(const CERTCertificate*, const CERTCertificate*, const char*, PRErrorCode, PRTime, PRTime)': /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:205:56: error: no matching function for call to 'mozilla::psm::OCSPCache::FindInternal(const CERTCertificate*&, const CERTCertificate*&, mozilla::MutexAutoLock&)' int32_t index = FindInternal(aCert, aIssuerCert, lock); ^ /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:205:56: note: candidate is: /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:117:1: note: int32_t mozilla::psm::OCSPCache::FindInternal(const CERTCertificate*, const CERTCertificate*, const char*, const MutexAutoLock&) OCSPCache::FindInternal(const CERTCertificate* aCert, ^ /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:117:1: note: candidate expects 4 arguments, 3 provided make[5]: *** [OCSPCache.o] Error 1 }}}
Let's see how it goes if I add the missing
aIsolationKey.Sorry -- I seem to have failed to re-push that fix. It should be correct now.
-
Replying to arthuredelstein:
Replying to gk:
Let's see how it goes if I add the missing
aIsolationKey.Sorry -- I seem to have failed to re-push that fix. It should be correct now.
That one fixes it but the build is still failing on Linux systems (have not tested the other ones yet):
pkix_pl_ocspresponse.c: In function 'pkix_pl_OcspResponse_Create': pkix_pl_ocspresponse.c:493:30: warning: passing argument 5 of 'hcv1->createFcn' makes pointer from integer without a cast rv = (*hcv1->createFcn)(serverSession, "http", ^ pkix_pl_ocspresponse.c:493:30: note: expected 'const char *' but argument is of type 'PRIntervalTime' pkix_pl_ocspresponse.c:493:30: warning: passing argument 6 of 'hcv1->createFcn' makes integer from pointer without a cast pkix_pl_ocspresponse.c:493:30: note: expected 'PRIntervalTime' but argument is of type 'void **' pkix_pl_ocspresponse.c:493:30: error: too few arguments to function 'hcv1->createFcn' make[9]: *** [/home/ubuntu/build/tor-browser/obj-i686-pc-linux-gnu/security/nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.o] Error 1 Replying to gk:
Replying to arthuredelstein:
Replying to gk:
Let's see how it goes if I add the missing
aIsolationKey.Sorry -- I seem to have failed to re-push that fix. It should be correct now.
That one fixes it but the build is still failing on Linux systems (have not tested the other ones yet): {{{ pkix_pl_ocspresponse.c: In function 'pkix_pl_OcspResponse_Create': pkix_pl_ocspresponse.c:493:30: warning: passing argument 5 of 'hcv1->createFcn' makes pointer from integer without a cast rv = (*hcv1->createFcn)(serverSession, "http", ^ pkix_pl_ocspresponse.c:493:30: note: expected 'const char *' but argument is of type 'PRIntervalTime' pkix_pl_ocspresponse.c:493:30: warning: passing argument 6 of 'hcv1->createFcn' makes integer from pointer without a cast pkix_pl_ocspresponse.c:493:30: note: expected 'PRIntervalTime' but argument is of type 'void **' pkix_pl_ocspresponse.c:493:30: error: too few arguments to function 'hcv1->createFcn' make[9]: *** [/home/ubuntu/build/tor-browser/obj-i686-pc-linux-gnu/security/nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_ocspresponse.o] Error 1 }}}
I'll work on fixing this. I developed the code on a Mac and had not tested linux.
Here's a new version of the patch, which also builds on linux.
https://github.com/arthuredelstein/tor-browser/commit/e6f769b4c5bfca8b7282627bb420c4c8b757974a
For some reason, the linux version of tor-browser.git wanted to build libpkix, whereas OS X did not. libpkix is off by default (security.use_mozillapkix_verification = true) in FF31 and removed completely by FF34. A new library, mozilla::pkix, is used by default instead. So I implemented first-party isolation in mozilla::pkix only. In libpkix a few
isolationKeyarguments are inserted for compatibility with headers, but allisolationKeysare set to NULL.-
This one is crashing for me on a 64bit Linux right after the browser window gets up. Probably when the first OCSP request happens. I had the locale patch as well in that build but I doubt it is the culprit. To be super sure I am just rebuilding without it.
The stacktrace gives just a crash somewhere deep down in libxul. We'll see if I can find more out by using our broken debug symbols.
Marking this as needs_revision in order to not lose time for looking for the bug (I'll change that again if the JS locale patch caused this).
Trac:
Status: needs_review to needs_revision -
There is supposed to be something wrong with our debug symbols (#13917 (moved)) but I think the following might be helpful, though:
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdaafe700 (LWP 3114)] 0x00007ffff3287941 in mozilla::psm::CertIDHash(unsigned char (&) [48], CERTCertificateStr const*, CERTCertificateStr const*, char const*) () at /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:79 79 /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp: No such file or directory. (gdb) bt #0 0x00007ffff3287941 in mozilla::psm::CertIDHash(unsigned char (&) [48], CERTCertificateStr const*, CERTCertificateStr const*, char const*) () at /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:79 #1 0x00007ffff3287d4c in mozilla::psm::OCSPCache::Put(CERTCertificateStr const*, CERTCertificateStr const*, char const*, int, long, long) () at /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:102 #2 0x00007ffff3287123 in mozilla::psm::NSSCertDBTrustDomain::VerifyAndMaybeCacheEncodedOCSPResponse(CERTCertificateStr const*, CERTCertificateStr*, long, unsigned short, SECItemStr const*, mozilla::psm::NSSCertDBTrustDomain::EncodedResponseSource, bool&) () at /home/ubuntu/build/tor-browser/security/certverifier/NSSCertDBTrustDomain.cpp:471 #3 0x00007ffff328747a in mozilla::psm::NSSCertDBTrustDomain::CheckRevocation(mozilla::pkix::EndEntityOrCA, CERTCertificateStr const*, CERTCertificateStr*, long, SECItemStr const*) () at /home/ubuntu/build/tor-browser/security/certverifier/NSSCertDBTrustDomain.cpp:411 #4 0x00007ffff328891d in mozilla::pkix::BuildForward(mozilla::pkix::TrustDomain&, mozilla::pkix::BackCert&, long, mozilla::pkix::EndEntityOrCA, mozilla::pkix::KeyUsage, SECOidTag, SECOidTag, SECItemStr const*, unsigned int, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>&) () at /home/ubuntu/build/tor-browser/security/pkix/lib/pkixbuild.cpp:292 #5 0x00007ffff3288aaf in mozilla::pkix::BuildCertChain(mozilla::pkix::TrustDoma in&, CERTCertificateStr*, long, mozilla::pkix::EndEntityOrCA, mozilla::pkix::KeyUsage, SECOidTag, SECOidTag, SECItemStr const*, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>&) () at /home/ubuntu/build/tor-browser/security/pkix/lib/pkixbuild.cpp:367 #6 0x00007ffff3285770 in mozilla::psm::BuildCertChainForOneKeyUsage(mozilla::pkix::TrustDomain&, CERTCertificateStr*, long, mozilla::pkix::KeyUsage, mozilla::pkix::KeyUsage, mozilla::pkix::KeyUsage, SECOidTag, SECOidTag, SECItemStr const*, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>&) [clone .constprop.2] () at /home/ubuntu/build/tor-browser/security/certverifier/CertVerifier.cpp:348 #7 0x00007ffff3285cbc in mozilla::psm::CertVerifier::MozillaPKIXVerifyCert(CERTCertificateStr*, long, long, void*, char const*, unsigned int, mozilla::psm::ChainValidationCallbackState*, SECItemStr const*, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>*, SECOidTag*) () at /home/ubuntu/build/tor-browser/security/certverifier/CertVerifier.cpp:479 #8 0x00007ffff3286095 in mozilla::psm::CertVerifier::VerifyCert(CERTCertificateStr*, long, long, void*, char const*, char const*, unsigned int, SECItemStr const*, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>*, SECOidTag*, CERTVerifyLogStr*) () at /home/ubuntu/build/tor-browser/security/certverifier/CertVerifier.cpp:620 #9 0x00007ffff32869f7 in mozilla::psm::CertVerifier::VerifySSLServerCert(CERTCertificateStr*, SECItemStr const*, long, void*, char const*, char const*, bool, mozilla::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>*, SECOidTag*) () at /home/ubuntu/build/tor-browser/security/certverifier/CertVerifier.cpp:1000 Replying to gk:
There is supposed to be something wrong with our debug symbols (#13917 (moved)) but I think the following might be helpful, though: {{{ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffdaafe700 (LWP 3114)] 0x00007ffff3287941 in mozilla::psm::CertIDHash(unsigned char (&) [48], CERTCertificateStr const*, CERTCertificateStr const*, char const*) () at /home/ubuntu/build/tor-browser/security/certverifier/OCSPCache.cpp:79 [snip]
This was indeed helpful. I think the issue is that
strlen(aIsolationKey)atsecurity/certverifier/OCSPCache.cpp:79is segfaulting whenaIsolationKeyis null.So here is a new version that checks if
aIsolationKeyis null and avoids callingstrlenin that case: https://github.com/arthuredelstein/tor-browser/commit/a3a21f0fd4c8cac6cb1a430132eb2ac42273ae8bUnfortunately my linux build of tor-browser.git is taking absolutely forever inside VirtualBox, so I haven't had a chance to check this directly myself. But I did confirm with a small test C program that
strlen((char *) NULL)segfaults.
The favicon portion of this patch checks and sets an nsINode attribute that specifies the first party. I believe this can be abused by content to set its own attributes to circumvent our domain isolation.
I also feel that the OCSP cache isolation is too invasive - it touches too many pieces of the code. This patch seems very unlikely to be taken by Mozilla. We need to find a less invasive way of isolating the OCSP cache and requests.
So that #13766 (moved) can still move forward, I pushed a Torbutton commit that keeps the circuit dirty timeout at 10 minutes for requests that we can't find a first party for.
We can perhaps revisit this during/after the ff38-esr rebase, but it is too large, untested, and risky for 4.5.
Trac:
Keywords: TorBrowserTeam201503R, tbb-4.5-alpha deleted, ff38-esr, tbb-linkability added
Status: needs_review to needs_revisionReplying to mikeperry:
The favicon portion of this patch checks and sets an nsINode attribute that specifies the first party. I believe this can be abused by content to set its own attributes to circumvent our domain isolation.
This is a good observation that I had missed. One alternative might be to add a SetIsolationKey method to nsINodes, that would only be accessible to C++ and chrome javascript.
-
Replying to mikeperry:
The favicon portion of this patch checks and sets an nsINode attribute that specifies the first party. I believe this can be abused by content to set its own attributes to circumvent our domain isolation.
I also feel that the OCSP cache isolation is too invasive - it touches too many pieces of the code. This patch seems very unlikely to be taken by Mozilla. We need to find a less invasive way of isolating the OCSP cache and requests.
So that #13766 (moved) can still move forward, I pushed a Torbutton commit that keeps the circuit dirty timeout at 10 minutes for requests that we can't find a first party for.
That's very unfortunate. While I agree we should not take the patches in this bug having different timeouts for different circuits depending on the load might reveal quite a bit of information which makes me quite uncomfortable. Not sure how much yet though and how serious this is as I currently can't think clearly about it due to last minute stress :-/
Replying to mikeperry:
The favicon portion of this patch checks and sets an nsINode attribute that specifies the first party. I believe this can be abused by content to set its own attributes to circumvent our domain isolation.
I'm posting a new version of 13670 (part I, favicons) here, that avoids this problem by checking that the nsINode is in chrome: https://github.com/arthuredelstein/tor-browser/commit/29d9ee9013a67f82e132539744e518d1daafebfb
It's probably useful to note here that there are two pathways for requesting favicons. The nsINode fix deals with the part of the code that injects an ordinary content image into the chrome
tabobject.Replying to mikeperry:
I also feel that the OCSP cache isolation is too invasive - it touches too many pieces of the code. This patch seems very unlikely to be taken by Mozilla. We need to find a less invasive way of isolating the OCSP cache and requests.
I think the OCSP patch may be less invasive than it looks. While a lot of files are involved, most of the changes are minimal, and involve simply adding an "isolationKey" parameter to an internal API call. The only potentially breaking change to an outward-facing API is in nsISocketProvider.idl. But this API is native-only, so it is unlikely to interfere with extensions.
I've been trying to find ways to make this patch smaller, and I'm open to suggestions, but given the existing code path from new HTTPS connection to OCSP request, I haven't succeeded in finding a good way to shorten it. (Mozilla did accept another patch from us which changes substantially more lines of code: https://hg.mozilla.org/mozilla-central/rev/04c452764339)
In case it's useful to understanding this patch, the code path of the isolation key string is as follows:
- The browser is making an original HTTPS request using an nsHttpChannel.
nsHttpChannel::BeginConnect()callsGetFirstPartyIsolationURIand passes it to thensHttpConnectionInfoconstructor (1). - Soon,
nsHalfOpenSocket::SetupStreams, called byHttpConnectionManager, gets the isolation key usingnsHttpConnectionInfo->GetIsolationKey()and passes it to a newnsSocketTransportinstance (2). -
nsSocketTransport::BuildSocketpasses it tonsISocketProvider::NewSocketandnsISocketProvider::AddToSocket(3). - The three implementations of these latter two methods in turn pass the isolationKey to
nsSSLIOLayerNewSocketandnsSSLIOLayerAddToSocket(4), which in turn assign the isolationKey to a newTransportSecurityInfoinstance (5). - The socket now needs to be verified:
SSLServerCertVerificationJob AuthCertificateis called, gets the isolationKey from theTransportSecurityInfoinstance (6). The isolationKey is then passed toCertVerifier::VerifySSLServerCert(7), toCertVerifier::VerifyCert(8), and then toCertVerifier::MozillaPKIXVerifyCert(9), the last of which instantiates anNSSCertDBTrustDomaincontaining the isolation key (10). - When
NSSCertDBTrustDomain::CheckRevocationis called, it passes the isolationKey toOCSPCache::Get,OCSPCache::PutandOCSPRequestor::DoOCSPRequest()(11).
Up to this point, all code has simply been passing the isolationKey down from the original http channel to the OCSP code.
- Now
OCSPCache.Get()andOCSPCache.Put()callOCSPCache::CertIDHash, which uses the isolationKey in its generation of the hash. (12). - The
DoOCSPRequestcall stores the isolation key in newnsNSSHttpRequestSessioninstance (in acreateFcncall). (13) - The
nsNSSHttpRequestSessioninstance creates a new nsHttpDownloadEvent, which uses the nsNSSHttpRequestSession's isolation key to set the document URI for a newnsHttpChannelfor the OCSP request (14). The channel's document URI set to ensure that when GetFirstPartyIsolationURI is later on the channel by torbutton's domain isolator, the same first party URI will be returned as that for the original HTTPS channel (16).
- The browser is making an original HTTPS request using an nsHttpChannel.
-
I tested the latest patches and the crashes are gone + the isolation seems to work as expected. Mike could you review the changes? I'd like to include the patches into 5.0a1. Oh, and in addition to Mozilla taking patches that are larger they declined to take a patch we ship due to complexity issues. Thus, I think we should ship the ones in this ticket while looking in parallel for a better solution after Mozilla officially declined to take our code.
Trac:
Keywords: N/A deleted, TorBrowserTeam201505R, MikePerry201505R added
Status: needs_revision to needs_review -
Issues I've spotted so far:
- It seems that in nsHttpChannel::BeginConnect(), the isolationKey is the full URI spec. Shouldn't it be using ThirdPartyUtil::GetFirstPartyHostForIsolation() instead of the full spec?
- nsHttpConnectionInfo::SetOriginServer() is also using the isolationKey here. This is going to cause much stronger HTTP Keep-Alive isolation than we originally had, esp if the isolationKey differs from how we use SOCKS u+p.
- I am made very nervous by the use of bare char pointers rather than nsCStrings for passing (and in NSSCertDBTrustDomain, holding) the isolationKey string. Are we absolutely sure the lifetime of the objects using the bare pointer is always shorter than wherever this isolationKey's pointer memory is held? This seems especially tricky because there are a couple of different places that hold a copy of the isolationKey, and it is hard to untangle which bare pointer is really held by which object. Is the additional string allocation+copy really a serious perf concern here? Otherwise, I think we risk some really annoying-to-debug UAFs, especially if the OCSP request handling is refactored, made more async, or otherwise further decoupled from the HTTP layer in future Firefox releases.
In fact, I suspect that it may be the case that our longer HTTP keep-alive is just causing us not to see more cases where issue 3 would cause crashes. If the original HTTPS connection gets torn down long before the OCSP request completes, I suspect we'll again see issues...
-
I think my concerns wrt to issue 3 at the moment are limited to NSSCertDBTrustDomain holding the bare pointer. If we make that be an nsCString, I think we may be OK, since the rest is just arg passing. But if any of these function calls suddenly become async in FF38 or later, we'll be sad again.
In the interest of getting us closer to 5.0a1, I will fix up my concerns in a fixup commit.. But I'd still like this to have more eyes (mcs+brade, ideally), and I'd like us to think about how we can protect against future issues.
-
Replying to mikeperry:
In the interest of getting us closer to 5.0a1, I will fix up my concerns in a fixup commit..
Testing the 5.0a1 the OCSP isolation does not work anymore (it worked while testing the arthur's latest patches in comment:34). The catch-all-curcuit is used for me as without the patch. So I guess either your fixups are causing this or some interference with #15933 (moved). Either way this needs revision.
Trac:
Status: needs_review to needs_revision 
Kathy and I did our best to review these patches. We are not 100% sure, but it seems like the change Mike made to use a hostname for isolationKey will break the code inside nsHTTPDownloadEvent::Run() that passes that string to NS_NewURI(). It would be good to add a check for failure there in any case.
With respect to memory ownership and lifetime issues, it is difficult to be certain but Kathy and I think the code is OK. From an auditability point of view, using string classes would make things easier.
A few more comments:
-
The GUID for nsISocketTransport.idl should be updated.
-
The second parameter to ReportFailedToProcess() is always an empty string. Why add the parameter?
-
Inside TransportSecurityInfo, the getter that has this signature is not called:
nsresult GetIsolationKey(char **aIsolationKey);
Can we remove it? Also, it might be good to follow the example of GetHostNameRaw() and rename the other GetIsolationKey() method to GetIsolationKeyRaw().
-
After submitting the patch "Bug 13670.2: Isolate OCSP requests by first party domain" (and other related patches) to Mozilla Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b5b5088b96a5
It seems the patch defines a variable 'rv' that is never used: https://github.com/arthuredelstein/tor-browser/commit/a152437e8429469ac27807744455138fe48ae82b#diff-6f45031d8280c2357ad3baa0500fa764R114
Here's a new fixup patch that addresses issues mentioned in comment:38 and comment:40. I fixed the code in nsHTTPDownloadEvent::Run by prepending an "https://" scheme to the isolation domain.
https://github.com/arthuredelstein/tor-browser/commit/c95f25a009d421a7cf38e56cc4c6fe83ff43c438
I tested this patch and confirmed that most OCSP requests are isolated to the first party domain. However, some OCSP requests go on the No-First-Party circuit, apparently because they are prompted by favicon requests or Tor Browser update requests.
Trac:
Status: needs_revision to needs_review-
Replying to arthuredelstein:
Here's a new fixup patch that addresses issues mentioned in comment:38 and comment:40. I fixed the code in nsHTTPDownloadEvent::Run by prepending an "https://" scheme to the isolation domain.
https://github.com/arthuredelstein/tor-browser/commit/c95f25a009d421a7cf38e56cc4c6fe83ff43c438
I tested this patch and confirmed that most OCSP requests are isolated to the first party domain. However, some OCSP requests go on the No-First-Party circuit, apparently because they are prompted by favicon requests or Tor Browser update requests.
This last case should be solved bu #16448 (moved), right? Or is there an additional issue here?
Replying to mikeperry:
Replying to arthuredelstein:
Here's a new fixup patch that addresses issues mentioned in comment:38 and comment:40. I fixed the code in nsHTTPDownloadEvent::Run by prepending an "https://" scheme to the isolation domain.
https://github.com/arthuredelstein/tor-browser/commit/c95f25a009d421a7cf38e56cc4c6fe83ff43c438
I tested this patch and confirmed that most OCSP requests are isolated to the first party domain. However, some OCSP requests go on the No-First-Party circuit, apparently because they are prompted by favicon requests or Tor Browser update requests.
This last case should be solved bu #16448 (moved), right?
Yes, in my manual tests, it is solved by #16448 (moved).
mentioned in issue #13766 (moved)