Privacy of Web PKI Revocation Mon Aug 28 2023 Client revocation checks can reveal client behavior to a certificate authority. A better solution than CRL and OCSP is short lived certificates. -------------------------------------------------------------------------------- Privacy of Web PKI Revocation ============================= Published Aug 28, 2023 - 8 min read /------- Table of contents -------\ | Table of contents | | * Privacy of Web PKI Revocation | | * The presentation | | * The superior solution | \---------------------------------/ I attended a presentation at the Crypto and Privacy Village, where Matthew McPherrin [L1] 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. /[jacobi: surprise]------------------------------------------------------------\ | 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. [I1: The central problem with revocation, browser users have to contact certificate authorities to determine if it is revoked.] 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. [I2: A certificate view for lencr.org. In the certificate fields list Authority Information Access is highlighted. In the field value it has an OCSP Responder URI set to r3.o.lenc.rorg] 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. /----------------------------[jacobi: glassy-tears]----------------------------\ \------------------------------------------------------------------------------/ 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. /-----------------------------------------------------[kyrmeso: do-you-mean-me]\ | What about API clients? You know the whole microservice things and internet | | connected printers? | \------------------------------------------------------------------------------/ /[jacobi: sweating]------------------------------------------------------------\ | API and application clients often lack CRL and OCSP checking. Some do not | | check that the TLS CA Signature is trusted either. | \------------------------------------------------------------------------------/ /[jacobi: dot-dot-dot-surprised]-----------------------------------------------\ | 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. -------------------------------------------------------------------------------- Certificate Revocation List (CRL): A Certificate Revocation List (CRL) contains a list of all the revoked serial numbers of certificates that are not yet expired and should not be trusted because their respective key has been compromised. This list can grow to be as large as megabytes and is unsuitable for constrained devices. The CRL is signed by the CA and transmitted over HTTP. Transport Layer Security (TLS): A protocol, sometimes confused as SSL (its predecessor), which enables plain text protocols like HTTP to operate over a secure channel. The channel establishes a symmetric key with asymmetric cryptography and allows for authentication of server to client. When the client authenticates to the server over TLS, it is called mutual-TLS, or mTLS. Certificate Authority (CA): A Certificate Authority is a trusted entity that can create signed certificates of others public keys for a specific purpose. Most CAs are trusted indirectly with an intermediate certificate issued by a root authority which is trusted by the platform, browser, or application. Online Certificate Status Protocol (OCSP): The Online Certificate Status Protocol is an alternative to Certificate Revocation Lists (CRL). It can be used to verify if a certificate is valid or revoked in real time and is a requirement for CAs to implement. However, it is often not implemented for user applications these days. The response is signed by the CA and transmitted over HTTP. Automatic Certificate Management Environment (ACME): The Automatic Certificate Management Environment is described in the IETF standard RFC8555 [L2]. It is a protocol that allows a server to obtain a certificate for its hostname after proving it has access to control the content on that hostname. Many servers obtain certificates using ACME with providers like LetsEncrypt. Certificates issued through ACME often have shorter life times, such as 90 days. Man-in-the-Middle (MITM): A Man-in-the-Middle attack is where another actor is between two others having an honest exchange, where they are able to intercept and modify the exchange without honest actors detecting it. Internet Engineering Task Force (IETF): The IETF is a standards organization for the internet composed of volunteers. IETF working groups collaborate to produce RFCs that standardize internet technologies. [L1]: https://www.linkedin.com/in/mcpherrinm/ [L2]: https://www.rfc-editor.org/rfc/rfc8555.html [I1]: https://c.cdyn.dev/O8NanpqB [I2]: https://c.cdyn.dev/RWe7RlkG