Mitigate privacy concerns related to HTTPS certificate revocation checking

[garrettr]

We are introducing first-class support for HTTPS certificates on the SecureDrop .onions in the 0.4 release (#1928, #1934). @fowlslegs brought up potential privacy concerns due to OCSP revocation checking in #1929, which got me thinking about the issue.

Tor Browser has OCSP checking enabled by default. The OCSP requests are made by Firefox's networking/security library (NSS) and therefore go through the proxy and over Tor, so OCSP request do not leak the user's IP address. There appear to be some additional privacy-related mitigations implemented (e.g. Bugzilla #1264562), but more research is required to fully analyze the current state of affairs in the latest stable release of Tor Browser.

Even with these mitigations implemented, if a SecureDrop Source Interface uses an HTTPS certificate with an OCSP endpoint configured, the OCSP checks will leak timing information about source's activity to 3rd parties. Specifically, when a source accesses an HTTPS-enabled SecureDrop page for the first time in a given Tor Browser session, Tor Browser will make an OCSP requests to the OCSP endpoint operated by the certificate authority to check the validity of the SecureDrop Source Interface's HTTPS certificate. OCSP requests contain a unique identifier for the certificate being validated, so it is possible to correlate OCSP requests with activity on a specific HTTPS-enabled SecureDrop instance.

The OCSP request leaks the following information to the following 3rd parties:

• The certificate authority learns that a Tor user made a request to a specific SecureDrop instance, and the timing of that initial request. Since the OCSP response is cached by the browser, the CA does not learn the timing of subsequent requests (until the Tor Browser is restarted and the OCSP cache is cleared).
• Since OCSP does not mandate encryption, the same timing information may be leaked to the Tor exit node of the circuit used for the OSCP request, as well as any intermediary servers between the exit node and the OCSP responder (e.g. CDNs).

The best solution is probably to mandate the use of OCSP stapling with OCSP Must-Staple for SecureDrop's implementation of HTTPS, but more research and testing is needed.

[garrettr]

OCSP's privacy problems have been well known for some time, and mitigating them was one of the primary motivations behind the creation of OCSP stapling.

Unfortunately, my research suggests that there are persistent, ongoing problems with the OCSP stapling implementations in popular web servers (including Apache, which is the web server currently used in SecureDrop). See Hanno Böck's The Problem with OCSP Stapling and Must Staple and why Certificate Revocation is still broken for details.

[garrettr]

After further research, I think it's important to distinguish between the tradeoffs of implementing OCSP stapling vs. implementing OCSP stapling with Must-Staple.

OCSP Stapling

• Key benefit: resolves privacy concern around leaking timing information to third parties. Since the revocation status information is checked by the server, and sent to the client in the TLS handshake, the client does not contact any 3rd parties during the TLS handshake and thus does not leak any timing information related to source activity.
• Easy to implement: only requires changes to server configuration (e.g. How To Configure OCSP Stapling on Apache and Nginx).
• Downside: not resistant to MITM attacks; however, this may be less of a concern in the SecureDrop use case because we are using HTTPS on top of a Tor Hidden Service.

OCSP Must-Staple

• Key benefit: makes OCSP stapling resistant to MITM attacks, which makes revocation checking reliable and therefore secure.
• Harder to implement because it requires issuing a new certificate.
• According to Hanno's blog post, Must-Staple cannot be used safely with current popular web server's implementations of OCSP stapling due to the potential of failure modes that could lock users out of a site for extended periods of time.

Takeaways

We may be able to roll out OCSP-related changes to SecureDrop's HTTPs configuration iteratively. For example:

1. Implement OCSP stapling in the web server configuration, without implementing Must-Staple. This would mitigate the timing leak, and although revocation checking will not be as secure as it should be, that may be less of a concern in the SecureDrop use case because an attacker would also have to MITM a Tor Hidden Service.
2. Carefully consider implementing Must-Staple or other techniques to fully secure HTTPS certificate revocation checking in the SecureDrop HTTPS configuration.

Such an iterative roll-out would be beneficial because:

• It seems relatively easy to implement OCSP stapling
• It would resolve the privacy concerns
• The potential side-effects are minimal.

Ideally we would also implement Must-Staple to make revocation checking fully secure, but:

• Revocation checking is a mess in general, and the default is to use online OCSP, which is subject to the same MITM attacks as OCSP stapling without Must-Staple. So implementing OCSP stapling without Must-Staple is not ideal, but it would not be a regression either.
• Must-Staple apparently has the potential to create serious negative side effects on the availability of SecureDrop services. Such potential effects would have to be carefully tested before we could deploy or recommend deploying Must-Staple.
• Tor Browser/Firefox has an alternative revocation status mechanism (OneCRL) that is worth investigating as an alternative to OCSP Must-Staple.

[redshiftzero]

Great analysis @garrettr. Worth restating for an observer: the 3rd party here can only learn the time that a generic Tor user gets the certificate for a given SecureDrop instance. The information leak is comparable to an adversary positioning themselves as an HSDir for a given onion service - also currently possible and also provides the same timing information when the client requests a given onion service descriptor. In fact, that would be easier to do than the OCSP leak described here, since HSDirs are predictable - you wouldn't need to rely on either random chance that you are along the path of a source accessing a given SecureDrop (in the case of a malicious exit node) or being in a privileged position (in the case of a malicious OCSP server or CDN).

That said, I agree that we should add OCSP stapling to the HTTPS config and test this out ourselves with an EV cert for the next minor release (0.4.1). For 0.4 (currently undergoing QA prior to release), let's add a note to the HTTPS documentation linking to this issue.

[garrettr]

Cloudflare just blogged about their work on creating reliable infrastructure for OCSP stapling. While their work is not directly applicable to this issue, the blog post might be interesting to some folks for background on the history of certificate revocation as well as a detailed description of some of the common issues encountered when deploying OCSP stapling.

[legoktm]

There's some relevant discussion in this Tor Browser ticket: https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41115#note_2850747

Generally Firefox is trying to move from OCSP to CRLite (https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-web-pki-revocations-compressed/).