Encrypted Client Hello: The Future of ESNI in Firefox
blog.mozilla.org
blog.mozilla.org
However, to make it work, they need the server's public key out of DNS. To get that, they didn't rely on preexisting TLSA records intended for this purpose (partly because it wouldn't work in some cases, TLSA can either contain fingerprints or pubkeys). Instead, they defined a whole new DNS record type to publish those keys. But those records, called SVCB, don't just publish keys. They are an amalgamation of SRV records (this service called "something" is actually at that host and port), CNAME records and a list of key/value-properties with associated priorities. If you think you might know that one, yes, it looks almost like all of DNS inside DNS again. Just another Meta-DNS, because all those RRs aren't fancy enough already. Or maybe Cloudflare just wants a way to put all their internal routing info into DNS somehow.
Anyways, I'll wash my eyes with soap now...
I suppose it does if you run your own resolver?
Things changed since then, now plain DNS is also allowed.
That is, an ECH implementing browser talking to some web site that doesn't do ECH will present it an ECH blob which is random gibberish. The web site doesn't do ECH, so it ignores the ECH, but a middlebox doesn't know that and if it wants to "block ECH" it must tear down this connection.
If the same browser connects to a site which does have ECH the ECH blob isn't gibberish it's encrypted, the site decrypts it and treats the result as the real ClientHello.
Historically China's Great Firewall is willing to put work in to detect and sabotage things it doesn't like. But the point of GREASing extensions is to ensure that the extension itself isn't poisoned. As a result most likely ECH will work fine in China, they'll just block IPs they don't like, punish citizens (or indeed visitors) they don't like, and that's an internal matter that the Chinese can take up with their government in the usual (and costly) way.
This is not a magic anti-censorship tool, and isn't designed to be one. Even Tor isn't that, although its developers can point you at services that help if that's what you need.
Regarding blocking, what prevents Chinese firewall from simply removing ECH extension from all ClientHello packets? Servers that don’t expect ECH would continue to work, those that expect wouldn’t accept connection, mission accomplished.
Remember the IP address you connect to already tells a hypothetical eavesdropper roughly what you connected to. If it's a Wikimedia server or Microsoft is not concealed by lacking SNI. What ECH does is hide exactly which service you wanted from that IP address. Wikimedia run not only their famous encyclopedia, but a dictionary and numerous other useful references - from the same IP address with different hostnames. So maybe a future ECH-enabled German Wiktionary will use the same outer name as the English Wikipedia. Today an adversary can see which I am using, with ECH they cannot.
> Regarding blocking, what prevents Chinese firewall from simply removing ECH extension from all ClientHello packets? Servers that don’t expect ECH would continue to work, those that expect wouldn’t accept connection, mission accomplished.
The entire handshake is integrity protected. In TLS 1.3 (ECH is not proposed for any earlier versions) the transcript recorded by the server and client would deviate (one sent ECH the other did not receive it) and so the transcript signature check step fails and the connection doesn't work.
The Chinese don't bother messing about with this stuff, if you connect somewhere the Great Firewall thinks you shouldn't, it just closes the TCP connection and blocks traffic altogether. Simple, effective, and in a sense, standards compliant.
Seems like a very bad idea to me, but it's their country and they can choose policy. I think Winnie the Pooh is smarter than Trump and won't just throw a tantrum because he didn't get his way, but it's certainly possible he'd decide to turn every iPhone in China into a brick rather than accept that we don't want to keep telling eavesdroppers which server name you wrote in the URL.
The GREASE isn't there primarily because of China, as I said they don't build crazy fragile technology, they don't have anybody to sell this too, the Great Firewall is an in-house project, so it's mostly simple and robust. Bad destination IP, connection blocked. Rarely a big problem in a technical sense.
GREASE is because of stupid corporate middleboxes. Middleboxes are a technical problem, because even when they have an apparently mundane and legitimate purpose they tend to go about it in stupid over-complicated ways that destroy forward compatibility. All of the weird spelling of TLS 1.3 is because of middleboxes. Why is HelloRetryRequest spelled ServerHello? Because if you don't say ServerHello at that point some famous middleboxes explode. Why is TLS 1.3 ClientHello written exactly like a TLS 1.2 ClientHello (including the version number) except with crazy extension values? Because otherwise middleboxes explode. Why is there a bunch of completely random data labelled "Session ID"? Is it a session ID? Nope. If that was missing, you guessed it, middleboxes explode.
Honestly, the next version of TLS should have a mandatory variant of certificate caching [0], except instead of putting the cached_info in the ClientHello message, the final handshake message (which is encrypted) would include the hash of the cached certificate. If the hash doesn't match, then the server would send the certificate (the connection is now in an encrypted but unauthenticated state).
If nothing is cached, the client sends randomly generated bits in place of a cached certificate hash, which eliminates one case to be handled in the protocol. (Handle an empty cache and a stale cache in the same code branch.) This provides more privacy than sending an "I have nothing cached" and it's more likely to be struck by lightning and a meteorite simultaneously than get a 256-bit collision. The consequences of a hash collision are only that the connection needs to be reset.
In the case of nothing being cached, again to reduce the number of special cases to handle, the client would need to make a guess as to the ECDH/RLWE/etc. parameters in its initial handshake message. The mechanism for handling stale cached ECDH/RLWE/etc. parameters would then apply to the non-cached case. (In this case, the server just sends back a message saying "Those are stale. Here are my parameters for a method in your provided list of supported methods, and here, also have my first side of the handshake."). Again, eliminating special cases by faking it/guessing if nothing is cached slightly increases privacy by requiring information outside of the handshake to detect if this is a repeat visit.
This change would force any meddling middle box to go through MITM'ing most of a TLS handshake before getting much information at all, and then having to break the MITM'd connection and allowlist/denylist* the involved IP for some period of time. For scalability, most present-day censoring hardware keeps the censorship out of the main path, passively observing traffic from a router's cloned port, and submitting forged RST packets to both sides of a TCP connection when the plain text contains something it doesn't like. Forcing MITM'ing makes such meddling orders of magnitude more expensive to implement, and much less accurate in cases of shared IP addresses.
On a side note, I heavily use the trick of initializing a cache to expired values in order to avoid special-casing empty caches. There's a cute trick for caching conversion of ISO-formatted date strings to date objects if your hot path includes a lot of parsing of dates from JSON and only dealing with consecutive days (in my case, yesterday and today) the least significant bit of the rightmost day digit code point and the least significant bit of the rightmost month digit code point form a very cheap 2-bit hash that never collides for consecutive dates, so you can use a 4-element array as your cache. These digits are at constant offsets in the ISO date string from the year 1000 to the year 9999. (There are no consecutive even days, and consecutive odd days only occur when the month rolls over. Months always alternate even and odd, even at the rollover from 12-31 to 01-01. Every character set I'm aware of puts the digits consecutively, so this trick works for unicode, ASCII, and every character set I'm aware of.)
[0] https://tools.ietf.org/html/rfc7924
* formerly known as whitelist/blacklist
They allude that this could be possible in the spec.
> This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to [HTTPS-RR], though other delivery mechanisms are possible.
If you don't validate who you're talking to, some ISP will run a MITM attack simply to log accessed hostnames (even if they can't MITM the final TLS connection)
In fact, the firefox implementation for ESNI, and I assume now for ECH, required DNS over HTTPS to be enabled in firefox for ESNI to work. That means that if ESNI is used the domain is never transmitted in plaintext. However, it has the signfificant downside that if you can't or don't want to use Firefox's DoH, and your system DNS is already encrypted (DoH, DoT, VPN, etc.), then you can't get ESNI.
https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
For A vs AAAA that's fine, you don't need both to be consistent you just want either of them to work.
For ECH this could mean you get told key A (from yesterday), target name B (just changed now) and port number N (six hours old) and then when you try to connect to port N with key A and target name B that combination doesn't work.
So by bundling everything you need into a single record means the only remaining problem is that a cached record might be out-of-date, an ordinary routine mistake by operators that happens for any DNS records.
The other reason is dirtier and practical: We want all this information to make (for example) a web browser work. So why have the web browser always make fifty queries when there could be one query that encapsulates everything needed?
Also, http(s) within SVCB is an ugly special case to be handled differently than other SVCB records. And one SVCB answer doesn't contain all you need. E.g. there is no intent to be a replacement to or consistent with TLSA entries, so you will still need to do mutiple queries. It just contains the ECH key, so it rather looks like a half-baked kludge to make ECH work somehow.
There are not many ESNI-enabled websites on the web, but Cloudflare's CDN offers ESNI service. Thus, one can use ESNI for websites that use Cloudflare.
I have been testing ESNI for a while now. I use it for reading websites text-only with no ads or tracking. I use links; I am not a fan of "modern" browsers. IMHO, Cloudflare's ESNI is very fast. It seems even faster than normal TLSv1.2 or TLSv1.3.
https://defo.ie is one source for ESNI info, including links to source code on Github for ESNI-enabled openssl, curl, lighttpd, etc. If you compile the ESNI-enabled openssl from Github, below is a one-liner and a small script to try ESNI out.
First you must fetch an ESNI key in a TXT RR from Cloudflare DNS. Then you use the key to submit HTTP requests for about an hour, until it expires. Then you must get a new key.
# one-liner to fetch a key
# if you run your own DNS you could then put this into a TXT RR in your own zone file
#!/bin/sh
curl "https://cloudflare-dns.com/dns-query?name=_esni.www.cloudflare.com&type=TXT&ct=application/dns-json"|grep -o [/][^\\]* > esnirr
# try out ESNI using the key
# usage: echo https://some.cloudflare.website.com|$0
# usage: $0 HEAD < file-of-urls-with-same-domainname -- (http/1.1 pipelining)
#!/bin/sh
read k < esnirr
exec 2>/dev/null
(while read uri;do case $uri in http://*)uri=${uri#*http://};;https://*)uri=${uri#*https://};esac;
export host=${uri%%/*};path=/${uri#*/};test ! ${#path} -gt ${#url}||path=/;
printf ${1-GET}' '$path' HTTP/1.1\r\nHost: '$host'\r\nConnection: keep-alive\r\n\r\n';
done|sed 'N;$!P;$!D;$d';printf 'Connection: close\r\n\r\n') > .http;
host=$(sed -n '/^Host: /{s/.*Host: //;p;q;}' .http|tr -d '\r');
# Any Cloudflare IP should work - 104.16.249.249 is just one example
# https://www.cloudflare.com/ips-v4
openssl s_client -4 -tls1_3 -noservername -ign_eof -verify 9 -connect 104.16.249.249:443 -esni $host -esnirr $k < .http
rm .http
But still, it feels like such a hack throwing this into the DNS records. A mess for server operators to implement if you don't manage your DNS records via an API today (since they'll need to be changed when certs rotate). And I'm guessing that a wast majority of people use the ISP default DNS (or Google/Cloudflare), that brings plenty of privacy problems on its own...
Maybe ESNI/ECO is really worth the hassle in a future where the whole Oblivious DNS-thing[0] is widely spread.
[0] Someone like Apple would proxy your encrypted (DoH) DNS requests to Cloudflare, so neither Cloudflare nor Apple can see what a specific user is querying
This suffers from the same problem as the v4-v6 migration. There's simply no good way to solve it other than biting the bullet and laying the new v6 pipes. (Though this is a bit easier, but getting DNSSEC off the ground, the root signed, getting root rollover worked out ... all of that like v6 deployment took more than a decade, and it's just getting mainstream.)
I'm just thinking that if you don't have encrypted DNS queries, your basically still revealing similar info (at least on first/uncached connections).
If you use DoT to your ISP, they will have similar info. If you use DoH to Google/Cloudflare, they will have similar info.
How big is the privacy gain over cleartext SNI on first connection + client side caching of certs and encrypted SNI on later connections? Obviously it depends on your threat model, this + DoH/DoT to someone you trust would protect from plenty of things in an environment where a passive attacker can see your network traffic. But the question is who to trust...
But it's hopefully done properly this time. :)
It's the next logical step. There's no rush to implement it, even if it's nice and shiny.
Both Firefox and Chrome already has built-in support for DoH. So encrypted DNS is already getting taken care of.
There are an increasing number of providers to choose from: https://github.com/curl/curl/wiki/DNS-over-HTTPS
And rolling your own is always an option.
Info leak, trust a 3rd party, invest your time, pick your poison :)
I think the infoleak is not that serious, because in most cases a passive observer will have the IPs you connect to, and currently it's pretty easy to just enumerate the IPs of the "top 1 million websites" (I have no idea if anyone on Earth still uses the Alexa toolbar at all, or if it exists at all, but that list seems eternal somehow).
This is basically where the hiding in the noise strategy is made possible "thanks" to CDNs. If there are thousands of sites all hosted on a handful of IPs then correlating who views what is getting increasingly harder.
We shall see if this kind of slow but steady activism helps with government censorship on the long term or not.
(although the rollout of HTTPSSVC to all DNS servers and domain hoster APIs will probably take even longer than the phase-out of IE..)
Some DNS servers implement something they often call ALIAS, but it's basically the equivalent of having a crontab mirror the settings of the records you're referring to, and breaks eg. geo-dependent address resolving (so not that useful for referring to a CDN, which is why you'd most likely want this)
https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
- CNAME in the apex domain - Direct HTTP/3
Tbh, with the current implementation, ECH setup seems rather complicated to me. It benefits CDNs like CloudFlare since they control both DNS and the handshake process, but those who would like to setup ECH on their own are in trouble.
So you need another channel to pull a public key (or something comparable), and they picked DNS for that
Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information
If you do the key exchange on the connection, you have two choices:
a) anonymous key exchange, which could be MITM, because it's unauthenticated. This would be more secure than just sending the hostname in plain text, because it would require active interception rather than passive surveillance, but active interception is not that much harder than passive surveillance.
b) signed key exchange, which is tricky, because the server may have certificates for many hostnames, and it doesn't know which one you used
In order to have another option, you need to get a key through some other method. DNS is the more or less the most viable out of band method to get that information; after all, it's what you used to turn a hostname into an IP address to contact the server in the first place.
Having a trusted certificate for a domain you don't own is already the "Game Over" scenario for current TLS connections since DNS hijacking is generally much easier.
So for those unfamiliar, sniproxy is able to forward traffic to virtual hosts with their own encryption keys, by dispatching the connection based on the SNI of the handshake. After determining the correct vhost it initiates its own handshake with the destination and then hands the connection over to the original client, so the host running sniproxy does not need access to any keys or certificates.
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
Why a new record type, when TLSA records were invented for literally this exact purpose?
https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...