Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: SANS.edu Internet Storm Center - SANS Internet Storm Center SANS.edu Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

Encrypted Client Hello: Anybody Using it Yet?

Published: 2022-06-27
Last Updated: 2022-06-27 09:44:04 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

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|

Keywords: sni esni ech ssl pls sec603
0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

My Paste Command
Jun 26th 2022
1 day ago by DidierStevens (0 comments)

More Decoding Analysis
Jun 26th 2022
1 day ago by DidierStevens (0 comments)

Malicious Code Passed to PowerShell via the Clipboard
Jun 25th 2022
2 days ago by Xme (0 comments)

Python (ab)using The Windows GUI
Jun 24th 2022
3 days ago by Xme (0 comments)

FLOSS 2.0 Has Been Released
Jun 23rd 2022
4 days ago by Xme (0 comments)

Malicious PowerShell Targeting Cryptocurrency Browser Extensions
Jun 22nd 2022
5 days ago by Xme (0 comments)

Experimental New Domain / Domain Age API
Jun 21st 2022
6 days ago by Johannes (0 comments)

View All Diaries →

Latest Discussions

Dshield Sensor
created Jun 8th 2021
1 year ago by Rick (0 replies)

API port data
created Apr 25th 2021
1 year ago by JJ (1 reply)

RSS feed containing non-XML compatible characters
created Apr 14th 2021
1 year ago by Anonymous (1 reply)

Handler's Diary (Full text) RSS Feeds stopt working due to a typo
created Mar 5th 2021
1 year ago by bas.auer@auerplace.nl (0 replies)

port_scan issue in Snort3
created Feb 23rd 2021
1 year ago by astraea (0 replies)

View All Forums →

Latest News

Top Diaries

Mixed VBA & Excel4 Macro In a Targeted Excel Sheet
Jan 22nd 2022
5 months ago by Xme (0 comments)

A Quick CVE-2022-21907 FAQ
Jan 14th 2022
5 months ago by Johannes (0 comments)

Method For String Extraction Filtering
Apr 9th 2022
2 months ago by DidierStevens (0 comments)

CinaRAT Delivered Through HTML ID Attributes
Feb 11th 2022
4 months ago by Xme (0 comments)

Obscure Wininet.dll Feature?
Jan 21st 2022
5 months ago by Xme (0 comments)