6 ms·
This is extremely ugly. They got rid of ESNI because it was an incomplete solution possibly exposing the connection target anyways. So they decided to encrypt t
by corty 6y ago
This is extremely ugly. They got rid of ESNI because it was an incomplete solution possibly exposing the connection target anyways. So they decided to encrypt the whole client hello message, calling it ECH (encrypted client hello).
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...
- Koffiepoeder 6y agoIn that case, wouldn't it have been more logic to use eDNS OPT query fields instead?
- pas 6y agoProbably much harder than simply adding a new record resource type.
- LinuxBender 6y agoIf it depends on DNS, does that not expose the name being requested via DNS and defeat the point of ESNI? I guess I need to go read up on this. Reading Cloudflares blog, it appears they assume people are using DoH or DoT.
- Fnoord 6y agoNot if your DNS is encrypted (e.g. DNSCrypt, DoH, DoT, ...) I suppose it does if you run your own resolver?
- kevincox 6y agoBut your resolver still needs to fetch those from somewhere. So you need encryption somewhere in the chain.
- admax88q 6y agoDoH or DoT is encrypted. The address of the upstream resolver typically is hard coded or comes as a parameter during DHCP.
- pas 6y agoPlus both Firefox and Chrome has built-in DoH support.
- ameshkov 6y ago> it appears they assume people are using DoH or DoT Things changed since then, now plain DNS is also allowed.
- w3ll_w3ll_w3ll 6y agoIf the DNS query is done with DoT or DoH the server name is not exposed.
- LinuxBender 6y agoThat is what I took from their blog as well. For some reason I thought the original intent of ESNI was to do some type of opportunistic or self signed handshake for the (E)SNI portion to hide the requested name, then validate the actual site certificate. They must have run into a problem.
- ameshkov 6y agoI've been loosely following ESNI/ECH drafts, and I am not sure this approach (double handshake) was ever seriously considered despite that it sounds perfectly fine to me. It'd make the handshake heavier, but on the other hand, it'd also make it much harder to distinguish from the regular TLS traffic. On the contrary, ESNI/ECH seems to be easy to detect and block, and some countries (China, for instance) have already announced that they're going to do that.
- parliament32 6y agoThere was nothing stopping a MITM with a fake/self-signed pre-handshake.
- tialaramex 6y agoECH is intended to be GREASEd which means there isn't an easy way to say "Block ECH only when it is used" because the obvious markers are present in every single connection. 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.
- deleted 6y ago[deleted]
- shawnz 6y agoSince you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.
- LinuxBender 6y agoTrue. I guess I assumed incorrectly that the original design of ESNI would not require DNS be in the flow for the validation, meaning that if I had local DNS, or /etc/hosts entries, then nobody would see the name. But if special record types are required, then /etc/hosts or local DNS won't suffice. Just my opinion, but it feels like this was made unnecessarily complicated. Feels like some concepts from SSH (host keys, caching host keys) and web servers (default _server_ name) could have been used for this, since I don't really need to validate who I am talking to for passing the name.
- shawnz 6y agoHopefully, browsers and operating systems will add capacities to store the records locally. 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.
- londons_explore 6y ago> since I don't really need to validate who I am talking to for passing the name. 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)
- LinuxBender 6y agoTrue, but this would be pretty easy to spot. I am ok with the compromise of using the same method used with ssh host keys for passing the name. The browser can cache these keys and tell the person if things are changing. At least that would be much simpler than these additional DNS lookups and assuming people are using encrypted DNS to a trusted DNS provider, but that is a whole other discussion.
- Nullabillity 6y agoAren't SRV records CNAME-ish as well? So it kind of makes sense to see SVCB as SRV 2.0, I guess.
- pas 6y agoYep, just not widely implemented. Hence a new thing with new hopes. It looks really nice though, and it seems it has vendor support too. https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/ https://blog.cloudflare.com/speeding-up-https-and-http-3-neg...
- tialaramex 6y agoSo, one reason not to have this as like fifty separate DNS records is that consistency is essential. DNS doesn't provide any consistency guarantees, if you ask "A? foo.example" and "AAAA? foo.example" you are not promised that your answers represent the same moment in time, one of them might be brand new while the other has been cached for six hours and is now obsolete. 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?
- corty 6y agoDNS is never consistent, that is an explicit non-goal. You can also get a CNAME from last week pointing to a CNAME from 5 minutes ago pointing to a nonexistent hostname in a nonexistent zone. This feels very much like hammering on DNS to make it look like a bad copy of etcd or something. 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.
- 1vuio0pswjnm7 6y agoIn studies I have done, most websites on the internet do not require SNI. Thus with most websites there is no problem of domain names in plaintext being sent in ClientHello packets, and no need for ESNI. 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 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 It seems that connecting to cloudflare-dns.com to fetch the initial key via DoH requires SNI. Why not have a bootstrap server that is not on a shared IP and hence does not require SNI. # 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 "Modern" browsers are stupid. They are sending domain names in the clear even when the website is not using SNI. https://github.com/kontaxis/snidump https://github.com/kontaxis/snidump
- chaz6 6y agoI agree the whole design is horrible. I would much rather have had no DNS records whatsover, and instead used onion-style layered TLS, rather like how 802.1X works with outer and inner authentication. The browser would first initiate a TLS connection to the IP address, using the IP address as subject name. It then creates a second connection inside the first using the domain name as subject name.
- fpoling 6y agoHow the authenticity of IP address is established then? Wouldn’t the server need a certificate for its IP?
- corty 6y agoEither for its IP or for the hostname that results from the reverse-lookup of the IP. The latter is easier to obtain (proof of ownership for IPs is cumbersome) and is often present anyways. It would need an additional DNS lookup, but the present suggestion involving SVCB would need that as well (along with all the other uglyness).