User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Steps to reproduce:
Forgive me if this is off base; I searched online but didn't find anything substantive about the interaction between ESNI and OSCP. I marked this report security-sensitive out of an abundance of caution, because it describes a way to reveal the server name of some ESNI-protected sessions. I only noticed this today and haven't done much investigation.
I used Firefox Developer Edition, 67.0b1 linux64.
- Start a packet capture.
- Go to about:config and enable ESNI:
- Browse to an ESNI-supporting (i.e. on Cloudflare) site. The OCSP details will differ depending on the site's CA, so probably not every site will exhibit the problem. I used !https://avaaz.org/. I also reproduced it also on a site with a Cloudflare Universal SSL certificate.
See the attached packet capture, esni-avaaz.org-ff67.0b1.pcap.
Packet 54 shows that ESNI is in use, in the absence of a server_name extension and the presence of an extension with type 0xffce.
Secure Sockets Layer
TLSv1.3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Version: TLS 1.2 (0x0303)
Session ID Length: 32
Session ID: 0adb221d6ff7f7f500126d30d4ba552b43297c892160a237...
Cipher Suites Length: 36
Cipher Suites (18 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 598
Extension: extended_master_secret (len=0)
Extension: renegotiation_info (len=1)
Extension: supported_groups (len=14)
Extension: ec_point_formats (len=2)
Extension: SessionTicket TLS (len=0)
Extension: application_layer_protocol_negotiation (len=14)
Extension: status_request (len=5)
Extension: key_share (len=107)
Extension: supported_versions (len=9)
Extension: signature_algorithms (len=24)
Extension: psk_key_exchange_modes (len=2)
Extension: Unknown type 65486 (len=366)
Extension: Unknown type 28 (len=2)
So far the server name has not been revealed to an eavesdropper: the client encrypts it with ESNI, and TLS 1.3 encrypts the server's certificate. But packet 97 is a plaintext OCSP request that reveals the certificate serial number:
Online Certificate Status Protocol
requestList: 1 item
A search for the serial number finds a match that reveals the server name.
commonName = *.avaaz.org
organizationalUnitName = Tech
organizationName = Avaaz Foundation
localityName = New York
stateOrProvinceName = New York
countryName = US
I don't know exactly what should happen, but the OCSP request defeats the purpose of ESNI. Suppose a network intermediary wants to block a site. DNS over HTTPS, ESNI, and TLS 1.3 mean that it cannot match on DNS queries, SNI, or the server certificate; nor even on the IP address without blocking unrelated sites. But it can make a blacklist of certificate serial numbers, then watch for OCSP requests/responses with serial numbers on the blacklist, and then infer (e.g. temporally) which TLS sessions they belong to, or take some other action such as blocking the client's source IP address.
esni prefs should additionally affect OSCP? Or maybe OCSP needs consideration in documentation about activating ESNI in Firefox?