[HN Gopher] Encrypted Client Hello: The Future of ESNI in Firefox
___________________________________________________________________
Encrypted Client Hello: The Future of ESNI in Firefox
Author : todsacerdoti
Score : 51 points
Date : 2021-01-07 18:47 UTC (4 hours ago)
(HTM) web link (blog.mozilla.org)
(TXT) w3m dump (blog.mozilla.org)
| corty wrote:
| 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 wrote:
| In that case, wouldn't it have been more logic to use eDNS OPT
| query fields instead?
| Nullabillity wrote:
| Aren't SRV records CNAME-ish as well? So it kind of makes sense
| to see SVCB as SRV 2.0, I guess.
| LinuxBender wrote:
| If 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.
| shawnz wrote:
| Since 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 wrote:
| True. 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 wrote:
| Hopefully, 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.
| Fnoord wrote:
| Not if your DNS is encrypted (e.g. DNSCrypt, DoH, DoT, ...)
|
| I suppose it does if you run your own resolver?
| ameshkov wrote:
| > it appears they assume people are using DoH or DoT
|
| Things changed since then, now plain DNS is also allowed.
| w3ll_w3ll_w3ll wrote:
| If the DNS query is done with DoT or DoH the server name is
| not exposed.
| LinuxBender wrote:
| That 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 wrote:
| I'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.
| [deleted]
| ameshkov wrote:
| Can anyone explain why is it designed this way? Why was it
| necessary to involve DNS into this? Was it unavoidable or is that
| all in the name of keeping 0-rtt possible?
|
| 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.
| unilynx wrote:
| You need to know if you're talking to the server you think
| you're connecting to, otherwise a man-in-the-middle could
| impersonate the server and intercept the handshake to see the
| hostname you're trying to connect.
|
| So you need another channel to pull a public key (or something
| comparable), and they picked DNS for that
| ameshkov wrote:
| As someone suggested in a different comment: handshake with
| one certificate, then send a new ClientHello that contains
| the desired hostname and "re-handshake" with the real cert?
| shawnz wrote:
| How do you validate the authenticity of the first
| certificate without revealing any hostnames?
| ameshkov wrote:
| If we're keeping this simple, then I'd say have IP
| address in subaltnames. Obtaining such certs shouldn't be
| a problem for CDNs, and possible for others as well
| (regarding free options: Let's Encrypt doesn't support
| that, but ZeroSSL does)
| MathiasPius wrote:
| How do you know that the first certificate was not produced
| by the MitM?
| corty wrote:
| The client initiates the connection and must know a key to
| encrypt the client hello with before the first packet. Unsigned
| DH is out because that would allow MitM and involve another
| roundtrip, cached certificate is only known on the second
| connection and hardcoded keys would be stupid. That leaves DNS.
| unilynx wrote:
| HTTPSSVC might, as a side effect, finally solve the problem of
| not being able to point the root of a domain (eg 'google.com') to
| a CDN.
|
| (although the rollout of HTTPSSVC to all DNS servers and domain
| hoster APIs will probably take even longer than the phase-out of
| IE..)
| _wldu wrote:
| Isn't that because CNAMES may not be combined with other
| records and SOA and NS are required on whatever.com?
|
| https://tools.ietf.org/html/rfc2181
| unilynx wrote:
| Yep. There was talk of ANAME records at IETF but that doesn't
| seem to be really going somewhere
|
| 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)
| corty wrote:
| SRV records would already support that is browsers would look
| them up. But unfortunately they don't.
| jagger27 wrote:
| OpenSSL doesn't support this yet, so neither does nginx.
| darkhorn wrote:
| ESNI is the only reason why I use Cloudflare in some of my web
| sites.
| superkuh wrote:
| So... the attack on this would be to take over the local
| nameserver (or even just system DNS resolution) of the clients
| trying to get to a domain and then serve your own public key?
___________________________________________________________________
(page generated 2021-01-07 23:00 UTC)