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.
A lot of great work has happened over the past few years in securing the web by strengthening encryption and improving user security indicators. This helps users make informed decisions to keep their online activity secure and private and to thwart network adversaries from profiling users. Man-in-the-middle attacks on the network often conjure images of someone breaking into a server room and installing some kind of interlocutor spyware device or splicing a network card. Repeatedly, though, the internet service providers that bring the Internet to consumers’ homes have demonstrated they will use their privileged position on the network to sell private information about consumer internet use or degrade services from competitors.
Policy fixes like network neutrality are still in play, but these threats aren’t unlikely one-offs that target individuals, they are systemic abuses by technology providers. Technology fixes, though, are seeking to limit the visibility of web activity, such as the names of websites one visits or the content they download, indiscernible to anyone except the requester and the actual website operator.
Significant strides in improving the strength of encryption that makes data in transit unreadable, such as TLS 1.3, have squelched out vulnerabilities that stem from aging cryptographic algorithms and ciphers as well as certain threats that can affect the confidentiality of communications when an encryption key is leaked or a nation-state attacker. However, metadata that is exchanged in the process of finding a server and securely establishing a connection, DNS and TLS with a Server Name Indicator (SNI), can still leak and poses both an existential privacy problem that is particularly troubling to vulnerable populations under repressive regimes as well as a method for sophisticated technology providers in ‘free’ societies to profile traffic for bandwidth discrimination, censorship, or profiteering.
ESNI is a proposal to plug a hole in an extension of the Transport Layer Security protocol (sometimes incorrectly referred to by its obsolete predecessor, SSL) which allows for encrypted communications to happen over a channel in a standard way for many applications. In the web’s early days, users would connect to a web server, such as Yahoo.com, and Yahoo.com would return a signed certificate that could be used to setup a secure communications channel.
However, as the web matured, methods for hosting many different sites on the same server or set of servers took off and there was no longer a 1:1 match for a domain name and a web server. SNI was an extension that lets a client, like a web browser, specify “I want Yahoo.com” so the web site provider could return the correct, unique certificate to setup the channel for Yahoo.com, even though it could also be serving lots of other sites too. However, the “I want Yahoo.com” is exchanged in plain-text before the certificate is provided and before an encrypted channel is established.
That means savvy technology providers could just look here instead of logging DNS requests for similar data on what host names to which a customer is attempting to connect. This is becoming far more viable as HTTPS Everywhere, user agent changes, and free certificate authorities like Lets Encrypt are making ‘secure by default’ the new reality for the web. More TLS means more encryption, but also more consistency in finding hostnames in SNI fields.
TLS is underpinned by a system of trust, particularly in the entities called Certificate Authorities that cryptographically sign certificates used to establish encrypted communications. However, certificate authorities are fallible, and some have failed due to security breaches or by failing to abide by the rules and mis-issuing certificates. Some of the most egregious offenses from failed certificate authorities like DigiNotar, Symantec, and WoSign/StartCom have resulted in technology solutions that make it possible to hold them accountable. Certificate Transparency (CT) logs are a public ledger of certificates issued by authorities that allow their behavior to be monitored, but also create central clearinghouses of certificates that can be looked up by name or serial number. More on that soon.
When a certificate is compromised, a certificate authority can revoke it. While normally a certificate has a limited duration noted by an immutable expiration date embedded into it, certificates may be prematurely revoked if the holder or the authority is compromised. The Online Certificate Status Protocol (OCSP) is a protocol clients like web browsers user to verify a certificate it receives is still valid. OCSP lets a client ask “I just received this certificate for Yahoo.com, but is it valid?” The request is obscure, but not secure:
The request has a one-way hash of the distinguished name and public key in the certificate as well as the serial number of the certificate. Unsalted hashes mean anyone could poll CT logs for all distinguished names, build their own hash lookup dictionary, and then compare this value to their dictionary. However, the unhashed serial number makes this far easier, as many CT logs support direct lookup of certificates by their serial number. In the following screenshot, you can see a trivial lookup to find out my lab virtual machine was connecting out to https://support.mozilla.org.
This is not a new vulnerability. In fact, RFC 6960, which defines OCSP, explicitly states:
Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol.
Incorrectly, some presume OCSP must be performed over insecure HTTP to address a address a ‘chicken and egg’ problem that would arise from trying to validate the certificate of a secure OCSP site to validate the certificate of another secure site. While implementation details could be non-trivial, solutions like pinning the TLS certificates of well-known OCSP responders could address that challenge.
It is important, though, to consider that in the cat-and-mouse game of threats to privacy and privacy-protecting technologies, OCSP is a more readily available source of metadata on users as HTTPS adoption increases, CT logs become mandatory and pervasive, and insecure OCSP communications dominate the responder implementations. As other privacy holes are addressed, such as DoH and ESNI, to keep users’ Internet activity private, OCSP is a challenge at scale to address as well.