RSS

Despite DoH and ESNI, with OCSP, web activity is insecure and not private

05 Jan

TL;DR

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.

Background

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.

Progress

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.

A couple of standards have gained traction to address these weaknesses in DNS and TLS, with proposals termed DNS over HTTPS (DoH) and encrypted SNI (ESNI), respectively.

DoH

DoH moves the plaintext game of ‘telephone’ whereby a client’s request to resolve a URL into an IP address may traverse many different servers operated by many different entities to look up and return the answer.  DoH moves this communication from an unencrypted channel to an encrypted one, which still requires one to trust the privacy policy of the entity servicing the request, but does not need to presume the good behavior of every intermediate network and DNS server in the mix.  This is a very good thing we will see rolling out in the next few years in a much wider adoption.

ESNI

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.

Problems

CT Logs

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.

OCSP

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:

oscprequest

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.

ctlookup

Summary

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.

 
Leave a comment

Posted by on January 5, 2019 in Uncategorized

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

 
%d bloggers like this: