Privacy of Web PKI Revocation

I attended a presentation at the Crypto and Privacy Village, where Matthew McPherrin presents on the various mechanisms Certificate Authorities expose to clients to clarify whether a certificate is revoked or not, and the privacy implications of those mechanisms. Matthew elaborated on Certificate Revocation Lists, Online Certificate Status Protocol (OCSP), OCSP stapling, and a superior alternative: short lived certificates. The privacy implications center around feeding the Certificate Authority unnecessary data on client behaviors as they verify whether a certificate is revoked or not.

This talk summary is part of my DEF CON 31 series. The talks this year have sufficient depth to be shared independently and are separated for easier consumption.

The Crypto and Privacy village came through on its other moniker for this presentation. It shared how certificate revocation works in practice and the privacy implications of each revocation method.

The presentation

The presenter reminds the audience how certificate acquisition works with Certificate Authorities (CAs) and then explains that another responsibility CAs have is to track and publish certificates that have compromised private keys.

Compromised private keys allow anyone with a man-in-the-middle (MITM) capability to put their service in front of a user agent or application with said key and it be accepted.

It is in the application's and users' interest to not accept revoked certificates. There are several methods to determine if a certificate has been revoked. Some involve the application or user's browser to contact the certificate authority.

Certificate Authorities are required to maintain Certificate Revocation Lists (CRLs). These list files can grow in size over time, up to megabytes in size. For network constrained devices, it is unreasonable for a client to download a trusted CA's CRL when establishing new connections.

CRLs are useful for other circumstances, such as informing network middleware of unsafe certificates and threat analysis. As for the privacy considerations, requesting a CRL does not identify the specific certificate the client is validating. Given that the pool of possibilities is for every certificate issued and not expired, the chances of a CA linking a client connecting to a specific host is negligible.

A lighter alternative to these file lists are Online Certificate Status Protocol (OCSP), an HTTP (not secure) protocol for clients to verify whether a certificate has been revoked or not. The OCSP response is signed with the same CA private key used for certificates. CAs are currently mandated to implement OCSP for clients. This is an expensive service to run — a CA has to respond to every TLS handshake made by clients.

There are several problems: OCSP from clients allow a CA to collect a massive amount of precise traffic data — an incredible privacy risk. People, and their browsers, do not get to choose which CA is used by the service they connect to. Another problem is that OCSP fails open; if there is a network outage, or the CA is disrupted, or a malicious actor is dropping traffic, then a client cannot verify that the certificate is not revoked. Chrome has since removed OCSP due to privacy concerns.

An alternate enhancement is OCSP stapling. This is a TLS extension which includes a recent OCSP response. It cached by the server and "stapled" to the TLS handshake sent to the client. It may be cached for seven days by the server. A server polling for OCSP verification every seven days does not reveal any behavior to the CA about people. As far as privacy goes, this is a fantastic implementation.

However, its adoption stagnated. There is no incentive for server technologies to support this extension.

Given that servers are not implementing OCSP stapling, OCSP has been removed from the client, and CRLs are not being checked, what protects people from compromised certificates?

Google Chrome and Mozilla Firefox have their own CRL-like lists, which maintain high value compromised certificates to block. These lists come with every browser update and can be rapidly distributed to people. As an example, financial and government institutions are prioritized into this list, where a small community forum will not.

What about API clients? You know the whole microservice things and internet connected printers?

API and application clients often lack CRL and OCSP checking. Some do not check that the TLS CA Signature is trusted either.

This insecure behavior makes it easier to reverse engineer networked applications and IoT devices.

The superior solution

There is a better solution, and it is one that we have proven can be deployed at scale: Automatic Certificate Management Environment (ACME).

Instead of 90 days, what if we deploy certificates that expire in 7 days? Certificate renewal happens anyway, it does not share any behavioral information to a CA.

Automated certificate rotation reduces risk for all parties involved with an established proven protocol. With ACME, we can serve people with low risk certificates and respect their privacy.