The first payload sent by a TLS client to a TLS server is a "Client Hello." It includes several parameters supported by the client, such as available cipher suites, to start negotiating a compatible set of TLS parameters with the server. 

One particular option, the "Server Name Indication" (SNI), lists the hostname the client is looking for. The client hello is sent in the clear and has often been considered a privacy issue or, for some network defenders, the last straw to hold on to gain insight into TLS encrypted traffic.

Encrypted SNI (ESNI) was an initial solution to the privacy problem. As the name implies, it encrypts the SNI option in the client hello. The encryption uses a key communicated via DNS. You will first see a DNS lookup for a TXT record _esni.[domain name]. This TXT record will return the public key to encrypt the SNI option.

ESNI solves a significant part of the client hello privacy problem. But other client-hello options may be used to fingerprint clients. Encrypting the entire client hello message is the next obvious option. This idea, Encrypted Client Hello (ECH), is currently an IETF draft [ECH]. The encrypted client hello options are wrapped into an unencrypted "Client Hello Outer" that is used as a vessel to transport the encrypted blob. This blob will look like any other client hello option to a server not capable of ECH. 

Instead of a TXT record to communicate the key, ECH uses new SVCB and HTTPS records. This record provides more flexibility to advertise different options and keys [HTTPSRR].

Despite these standards in the draft stage, browsers are adding support for them. For the most part, ESNI is considered "dead" at this point, and browsers actively support ECH, but it may not be enabled by default. One feature that may lead to SVCB and HTTPS records being more commonly used than similar protocols like DANE is that SVCB/HTTPS does not require DNSSEC. The client will be able to verify the authenticity of the server using the usual TLS certificates. The DNS messages remain unprotected. As pointed out in the IETF draft, a hostile resolve will be able to downgrade the DNS responses.

But back to the title: Is anybody using these fancy standards? I took a look at my DNS logs to see how many requests I am seeing (and how many of them result in answers):

DNS requests for HTTPS records are undoubtedly popular, with about one HTTPS request for every 4 A record requests. Also, about 20% of the responses to HTTPS queries include at least one answer. So this looks pretty good, but the answer section of the response will not provide an answer here. None of the answers included an HTTPS record. They exclusively include A or CNAME records, which is also perfectly legal.

And a little side note if you want to play with this: The "dig" utility, at least the version I used (9.16.1-Ubuntu), does not fully understand the HTTPS record type.

$ dig -t HTTPS example.com
;; Warning, ignoring invalid type HTTPS

This warning is easily overlooked. Instead, try:

$dig -t TYPE65 blog.cloudflare.com
...
;; ANSWER SECTION:
blog.cloudflare.com.    18    IN    TYPE65    \# 67 0001000001000C0268330568332D323902683200040008681229AEAC 40925200060020260647004400000000000000681229AE2606470044 00000000000000AC409252
...

To query HTTPS records.

But the short answer to the headline question: No. Clients try to use it, but servers are not yet supporting encrypted client hello. Know of any example sites using it? Any comments or other suggestions to improve the methodology? Please leave a comment.

Oh. And, of course, this looks like yet another DNS covert channel opportunity. 

[ECH] https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-14
[HTTPSRR] https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-10

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|