I don’t think this fact is well known yet, so I will document it here. If you configure DoH and ESNI in Firefox according to Mozilla’s instructions, you will still leak some destination domains because of OCSP (Online Certificate Status Protocol) requests, which are often plaintext HTTP and contain a certificate serial number, which can be looked up in Certificate Transparency logs.

There are only a few places online where this is mentioned, so I suspect that many people who try to enable DoH or ESNI according to an online guide will be vulnerable. I don’t know of any workaround, in Firefox, other than setting security.OCSP.enabled=0 in about:config.

2019-01-05: http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-not-private/

Certificate Transparency (CT) logs increasingly provide virtually every TLS certificate to be identified by serial number. Since OCSP responses are unencrypted and contain the serial number of the certificate as can be found in CT logs, as well as unsalted hashes of the certificate’s Distinguished Name and public key, these can easily be profiled to compromise the privacy of clients even in the presence of DoH and ESNI privacy protections.

2019-03-13: https://bugzilla.mozilla.org/show_bug.cgi?id=1535235

I don’t know exactly what should happen, but the OCSP request defeats the purpose of ESNI. Suppose a network intermediary wants to block a site. DNS over HTTPS, ESNI, and TLS 1.3 mean that it cannot match on DNS queries, SNI, or the server certificate; nor even on the IP address without blocking unrelated sites. But it can make a blacklist of certificate serial numbers, then watch for OCSP requests/responses with serial numbers on the blacklist, and then infer (e.g. temporally) which TLS sessions they belong to, or take some other action such as blocking the client’s source IP address.

Maybe the trr and/or esni prefs should additionally affect OSCP? Or maybe OCSP needs consideration in documentation about activating ESNI in Firefox?

2019-03-29: Use ESNI via Firefox HTTPS helper (#28168) · Issues · Legacy / Trac · GitLab

I revised the instructions in comment:5 to add the pref security.OCSP.enabled=0, because ​OCSP can leak the server name even with DoH, ESNI, and TLS 1.3 are used. (This was never a problem with meek because any OCSP leaks would have been of the front domain, not the covert domain.)

2019-08-13: https://www.usenix.org/system/files/foci19-paper_chai_update.pdf (Section 5.2)

Leakage in OCSP. For completeness, we note the certificate serial number in unencrypted OCSP (Online Certificate Status Protocol) messages can leak the server name. It can be, consequently, exploited for censorship purposes.

2019-09-25: Centralised DoH is bad for privacy, in 2019 and beyond | PowerDNS Blog

To achieve the goal of perfect privacy on untrusted networks (without running a VPN) will require us to:
4. Disable OCSP/make OCSP stapling mandatory, or replacing it by an alternate mechanism.

The bugzilla bug has been closed, with Mozilla opting not to do anything about OCSP leaks, other than improve the documentation. These are their recommendations for preventing OCSP leaks with ECH:

On the server side: implement OCSP stapling (as Cloudflare reportedly already does) or use short-lived certificates (I don’t know exactly how short the validity has to be to disable OCSP checks).

On the client side: disable OSCP checking the preferences.

https://wiki.mozilla.org/index.php?title=Security/Encrypted_Client_Hello&oldid=1248531#Interaction_with_Revocation_Checking

Interaction with Revocation Checking

Firefox supports various methods for checking whether certificates have been revoked including OCSP, OCSP Stapling and (experimentally) CRLite. OCSP requires querying the certificate’s revocation status with the issuing CA and so leaks information about the site a user is visiting. Consequently, sites deploying ECH should also use OCSP Stapling or short lived certificates which don’t involve any network communication and so improves user privacy (Cloudflare deploy OCSP Stapling universally). If sites do not use OCSP Stapling, then ECH still provides a substantial privacy benefit as OCSP responses are cached for multiple days and so the majority of site visits will be protected. In the longer term, CRLite will allow for privacy preserving revocation checking without requiring action by site operators.

Users who prefer improved privacy over the security of revocation checking can disable revocation via the browser UX in about:preferences (or in about:config by preference).