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
trrand/oresniprefs 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.