The difference between ECH and SNI is that while SNI includes the hostname in the ClientHello (the first TLS record indicating connection initiation), ECH includes an encrypted section in the ClientHello called ClientHelloInner, and the hostname is moved inside it.
The ClientHelloInner is encrypted using a public key made available over DNS, which is queried over DNS over HTTPS providers such as Google or Cloudflare DNS; plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key.
Doing so prevents ISPs and governments from analyzing your traffic. However, a CDN operator such as Cloudflare terminates TLS for your website, and thus traffic would be visible to them either way.
Now, to the non-technical part of it: while ECH provides a significant privacy improvement, I personally am against its implementation. Most ISPs enforce country-specific orders to block domains using a combination of DNS packet interception and SNI inspection. The legitimacy or sanity of such laws are a separate matter - countries would want to block websites that violate their laws.
If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China.
[1] https://blog.cloudflare.com/encrypted-client-hello/
[2] https://www.article19.org/resources/france-proposed-internet...
[3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records?
> Doing so prevents ISPs and governments from analyzing your traffic.
Don't think traffic analysis is thwarted. ECH plugs inspection of the only plaintext bits in TLS, which is not only abused by censors, but also by various 'well-meaning' middleware that made bringing upgrades to TLSv1.3 a nightmare.
> If we take away this last resort from governments...
You mention GFW, and we got GFW without ECH. Governments will government, nothing will stop them. That shouldn't stop us from shoring up our side of the equation. Because by that logic, Meta shouldn't e2ee WhatsApp or Browsers shouldn't OCSP / CRL. In fact, not having those sound scary to me; because governments aren't the only power hungry actor around. It wasn't long ago Meta was caught spying on the users of its data saver VPN (Onavo) for half a decade, if not more.
It seems with QC, there's this collective magical thinking that they offer this magical free lunch that is inaccessable via more traditional means. I don't get what the seemingly non-existent tradeoffs or optimizations that are being made to achieve this...
That's exactly why I'm in favor of it: it makes effective censorship impossible.
> If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3]
Note that those plans both thankfully failed.
> or blocking large swathes of the internet as is the case with China.
No free country would tolerate that.
Which countries do you have in mind?
I know a lot of Americans talk that way about America, but America tolerates quite a bit of government censorship (DMCA/SLAP), privacy violations (NSA/TSA), and civil rights violations (prison slaves, war on drugs).
Most of Europe will.
The natural alternative if blocking these protocols becomes unsustainable will absolutely be to require full decryption at our security edge. And that will provide drastically more information to us than we have now and will absolutely feel invasive.
The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors.
Not every government has the leverage, capability or power to do this. Client side blacklisting will be trivially circumvented if it actually goes into effect. The browser vendors all rejected the proposed Kazakh root certificate. And plenty of countries with pervasive Internet censorship don't have enough of a "domestic internet" to block large numbers of websites without a lot of people getting upset.
> If we take away this last resort from governments, they would react by enforcing client side blocklisting and DRMization as suggested in France[2], or force root certificate installation using legislation[3], or blocking large swathes of the internet as is the case with China.
You left out the fourth option, which is give up on their censorship aspirations. For most countries, censorship isn't important, and making it too hard will simply make it not worth it. China is of course different.
Most countries made entirely ineffective laws and didn't bother following up.
Cloudflare adopts the similar predatory Google posture of "we really really care about your privacy - nobody else should spy on you but us". Creepy!!
You don't even have to start with governments. ECH can just as well be used by trackers/ads/app telemetry etc to stop you from blocking them via Pihole.
Even better would be to explain why SNI exists. This in turn explains why CDNs like Cloudflare are interested in it. SNI allows CDNs to operate as intermediaries on a www where HTTPS is increasinglty mandatory for every website. With respect to the "privacy" of TLS it is peculiar to put ISPs and governments in one category and CDNs in another. If ISPs (without ECH) or CDNs (with or without ECH) are getting a list of every domain the user visits, then governments can get the same list by requesting it from the ISP or CDN.
The question, IMHO, is whether there are other possible technical solutions besides TLS SNI to allow multiple HTTPS sites to be hosted on the same IP. Is it possible to obviate the need to use a third party such as a CDN to solve this problem. Is it possible to obviate the need for duct tape solutions like ECH. ECH is proposed as a solution for the "plaintext domain names over the wire" problem. But that problem only exists because it's created by the use of SNI. And SNI exists to enable one to host multiple HTTPS sites on the same IP. Today, CDNs are the primary benefactors of SNI. They host 10s or 100s of 1000s of HTTPS sites on a limited number of IPs. These are the primary users and benefactors of SNI.
For example, consider this prototype, which some believe inspired the advertising company-sposonsored "QUIC":
https://curvecp.org/addressing.html
"An ISP or site administrator can easily run a huge number of CurveCP servers on a single global IPv4 address, even if the servers are independently operated with separate long-term public keys. This feature is provided by a simple extension mechanism in CurveCP addresses.
CurveCP servers are inherently anti-aliased, providing automatic virtual hosting and fixing some of the deficiencies in the "same-origin" policy in web browsers. This feature is provided by a simple domain-name mechanism in CurveCP addresses. If a site has two server addresses, and one server is down, a CurveCP client will quickly connect to the other address.
A CurveCP connection remains fully functional even if the client changes IP address.
CurveCP is fully compatible with existing NAT (network address translation) mechanisms; none of the above features require clients or servers to know the global addresses of their gateways."
ECH seems like a overengineered implementation when they could just have released TLS 1.4 which encrypts that section of the handshake.
But the two SNIs are because of GREASE particularly. They might be avoided if you didn't want to enable GREASE, but we definitely want GREASE.
The idea of GREASE is, whenever we might want to do something that's visible to third parties, we must sometimes do it anyway, at least as much as they can tell, so as to ensure they tolerate this when it happens so that when we did want it we can do it successfully.
For example GREASE extensions are just nonsense extensions you propose in a TLS connection today. Chrome does this. "Hey server, can you do BINGLE BONGLE?" and of course your server doesn't do BINGLE BONGLE because that's nonsense, but to a "Security device" which is "Inspecting TLS connections as part of our Next Generation Firewall Technology" it seems like maybe we want to do BINGLE BONGLE. How should it react? Well, it should do nothing because the specification is clear that if you don't understand what is said you should ignore it, but without GREASE we know in SSL, and TLS 1.0, TLS 1.1 and TLS 1.1 these devices would freak out for each new extension.
1.6GB of customer personal information in a CSV file POSTed to a competitor's Dropbox? Fine. Your web browser wanted to use NEW FEATURE? Alert! Attack detected - lock down the network, summon armed guards! So hence the invention of GREASE.
For ECH GREASE works by just always pretending we're doing ECH. If we want to talk to old-web-site.example we send an outer SNI of old-web-site.example and it doesn't matter what our inner SNI is, it can be random nonsense encrypted to nobody, because old-web-site don't use ECH anyway.
If we want to talk to ech-enabled-site.example our browser discovers oh, here's a key for ECH for ech-enabled-site.example and it says we should ask to talk to boring.example, so the browser encrypts the inner SNI of ech-enabled-site.example with the key, and provides an outer SNI of boring.example.
In both cases this looks the same to snoops, there's an outer SNI they can read and an inner SNI they can't read. Which is genuine? No way for them to know. But the server knows easily.
Between the article and the linked introduction, all of what you are looking for is explained.
Appeasement doesn't work. Maybe it's easier to remember that if you're British and so you had to watch Chamberlain's "Peace for our time" news reel in history class. The British Prime Minister, Neville Chamberlain, negotiated a deal with rising star German Chancellor Adolf Hitler, you've heard of him. Hitler agreed that Germany wouldn't start a massive European war in exchange for the British turning a blind eye to smaller wars he'd already started.
You may never have heard of Chamberlain, because it turns out that piece of paper with Hitler's signature on it was worth precisely what you'd expect, and we needed an actual War Prime Minister soon enough.
Now, the argument for appeasement is that sure, it doesn't actually work but it buys time. This is wrong because your opponents have the same extra time and they know precisely what they're doing whereas you're expending resources pretending (even if you correctly believe the appeasement won't work) that appeasement works.
> This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user and the website will be able to determine which website was visited.
But if you look at the inner/outer SNI part:
> The outer SNI is a common name that, in our case, represents that a user is trying to visit an encrypted website on Cloudflare. We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare. Because Cloudflare controls that domain we have the appropriate certificates to be able to negotiate a TLS handshake for that server name.
> The inner SNI contains the actual server name that the user is trying to visit. This is encrypted using a public key and can only be read by Cloudflare. Once the handshake completes the web page is loaded as normal, just like any other website loaded over TLS.
So Cloudflare sees it? That's definitely not the same as what they're describing, it's more of a wink-wink Applesque "trust me bro" style of "privacy" - a consolidation of traffic under the pretext of something else.
I also looked at the draft document they linked, and that seems to match up with what I'm understanding.
> If ECHClientHello.type is outer, then the server acts as a client- facing server and proceeds as described in Section 7.1 to extract a ClientHelloInner, if available.
So what does this actually protect against? Who will this benefit? Mostly people in censored countries and companies. This removes the last piece of information that can be used to block HTTPS traffic based on the site your visiting without being a party to the exchange.
I still think DoH is hot garbage and the way it has been implemented across browsers is an atrocity. It's actively harmful to security even if the spirit is in the right place. I've got no complaints about ECH.
Not sure if it's a hot garbage, but I don't see why it's better than DoT or DoQ, except maybe a use case for censored countries. DoT is faster and can be abstracted away from from HTTP. Presumably, DoH is more privacy preserving, because it runs on the same port and looks just like the rest HTTPS traffic. But I think a spying ISP can probably guess that it's a DNS traffic by where it's going. If it's an HTTPS connection over 443 going to a know DNS server, then it's probably a DNS request, thus I don't see added privacy here.
But from traffic administration, it is harder. As a an example, now your Smart Spying Device can phone home and it is going to be harder to block it.
Also, we are moving from your ISP knowing too much about you to Cloudflare knowing too much about you. It's one of the biggest DoH DNS services, often they see unencrypted HTTPs traffic, they also an exit node for iCloud Private Relays. ISP is left out, but Cloudflare seems to be able to consolidate this knowledge.
"no one except for the user and the website will be able to determine which website was visited"
That, I think we can all agree, is patently untrue. Cloudflare shouldn't be publishing blatant deceptions.
You can do something like ECH in a way that not even Cloudflare will see it (it being the connection contents rather than the name, since Cloudflare actually needs the name to route the connection).
The naive way to do it is to do one handshake with Cloudflare that the client uses to provide the "real" name and then another with the "real" server so Cloudflare can't see that. That is possible but then you'd need two handshakes, which is rather inefficient and probably means it wouldn't be used. The interesting question is can someone come up with a way to get that result without the inefficiency.
And that will cause blocks by IP. It's not like authorities in those countries care that much if a user can't access a not-blocked site, as long as they can't access a blocked one.
> This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user, Cloudflare, and the website owner will be able to determine which website was visited.
Which sounds more precise and correct. I very much agree that these details matter.
In this case, Cloudflare are acting as the ECH provider and as they already host the websites, they already see the connection plaintext.
> This means that whenever a user visits a website on Cloudflare that has ECH enabled, no one except for the user, Cloudflare, and the website owner will be able to determine which website was visited.
The second way is to return a “no error no answer” or an NXDOMAIN response to queries made to the use-application-dns.net.
I personally already use the second option to block DoH and cell phones seem to automatically figure out to use port 853 for DNS-Over-TLS on my home router Unbound DNS. I also null route most of the public DoH servers. People point out that DoH can be on any CDN IP but it never has been.
[1] - https://developers.cloudflare.com/ssl/edge-certificates/ech/
[2] - https://learn.microsoft.com/en-us/windows-server/networking/...
Of course this kind of filtering is useless to stop a determined user (in a bring-your-own-device environment) because they can trivially just run their own DoH endpoint.
This misfeature can't be removed from browsers soon enough. Its existence is totally contrary to DoH's threat model, since the people DoH is designed to protect you from are exactly the ones who can manipulate insecure DNS results for that domain.
On-endpoint filtering is not enough on a large scale. In a network with expected high level of security I don't trust the endpoint and censoring them is a feature, there is no moral or legal expectation of privacy, but data integrity would be nice.
I want to have my tv connect to YouTube, but not phone Sony/Samsung/whoever.
I want to be able to setup a pihole to block adds independently of the browser/device being used.
[1] https://chasersystems.com/blog/disabling-encrypted-clienthel... [2] https://chasersystems.com/discriminat/comparison/aws-network...
I don't think it's much more of a pain than it already was. You can disable the feature on your side if you don't want it, and block+log any traffic with ECH enabled. Hell, you can set up an intercepting proxy with your own CA if you want. That way, nothing gets out without at least getting logged.
Of course this becomes quite difficult if you don't own the devices you're monitoring, but that is kind of the point behind TLS/ODoH/ECH.
In ECH, we still only complete one handshake per session. If you've got the right key for the inner client hello, you'll complete a handshake with the certificate for the domain you're trying to visit. If not, you'll complete a handshake with a certificate for the domain in the outer hello and the server will send you the correct key so you can try again with a new session. The client gets to validate the right certificate.
many years down the road this is now an actual (with the problem cases handled) feature!
Individual servers hosting one single website won't benefit much though. Unless you do encrypted split-DNS, I guess.
So if you have a few folk who each want to self-host, you can group together to provide ECH across all your sites without leaking to each other more than you leak to any passive attacker today.
(Or if the user isn't using some form of DNS privacy like DNS-over-HTTPS/TLS, but then their domain connections are exposed regardless of whether their CDN/host implements ECH.)
This looks like one more attempt by cloudfare to recentralize the web. And it doesn’t address the issue that cloudfare still perfectly know which website you are visiting.
Did I miss something?
This is bad if you are a government, company, school or user that wants to inspect traffic coming out of black-box devices: it's harder to block all of Cloudflare. But this is good if you live in a country where service X is blocked because it threatens the local political power. For example, when Signal was blocked in some countries, it used a method named domain fronting to work around that. It relied on a mismatch between SNI and HTTP domains, and all CDNs blocked it in the end. ECH allows having the same result but with plausible deniability for the CDN.
Now of course, there's always a catch… Cloudflare used to provide its services to kiwifarms; and what constitutes a legal, or moral thing to do tends to vary around the world.
this is how they caught some guy at harvard that called in a bomb threat via tor. even those he used it, he was the only one in the dorms who used tor so it was traced back to him.
“Enabled by default for Free zones.”
cloudflare-ech.com is going to be blocked by the Great Firewall and every other state-level filtering apparratus approximately ten nanoseconds from whenever this blog was posted.
Cloudflare needs a bunch of not-objectionable-to-governments sites in the anonymity set. For these sites, being in the anonymity set has a cost (a few of your visitors can't get to your website) but zero benefit.
For the free plan customers, Cloudflare kinda doesn't care about slightly pissing them off. They aren't paying anything. As long as they aren't all so pissed off that all of them leave simultaneously, Cloudflare is free to take advantage of them for both benevolent (as here) and nefarious (other situations) purposes.
CloudFlare's giant footprint of free customers gives them an advantage: it's way more acceptable to roll out new potentially downtime-causing features to users who aren't paying than to businesses paying you hundreds to thousands of dollars per month. The free tier gives them a bit of leeway to experiment, and gives them massive amounts of data from around the world to tell them how those experiments are working.
The most important thing expected and confirmed in the deployability testing is that many of the middleboxes were allergic to new TLS versions de facto. TLS says clients announce the maximum "version" of SSL they can do, then a server chooses the same or any lower version e.g. 0x0303 means SSL 3.3 which in reality is named TLS 1.2. However most middleboxes react to any version they don't understand by freaking out, so you can't ever say you speak a newer version. The initial TLS 1.3 design chooses 0x0304 with 0x0400 also a possibility, but neither would be deployable for this reason.
The most important surprise was that middleboxes are so reluctant to allow people's web browsing to just break that they mostly instead don't implement any meaningful security at all in a certain edge case. This is surprising to an engineer but makes sense once you understand their business (they sell tiger-deterring rocks, they don't sell tiger insurance, so they don't care that the rocks don't work, they're relying on the fact that there probably aren't any tigers and if there are too bad for you trusting their useless rocks).
As a result of this insight RFC 8446 TLS 1.3 connections actually start like this:
1.3 Client: Hello some-server-name, I'm the TLS 1.2 client you were talking to earlier, just resuming our earlier conversation number #random-nonsense. Also, just thought you might like to know I support optional FLY CASUAL THIS IS TLS 1.3 with a bunch of parameters
1.3 Server: Hello, yes let's resume our conversation. I too know FLY CASUAL THIS IS TLS 1.3 and I've got a different bunch of parameters.
And then everything is encrypted. Which makes sense, we said we're resuming a TLS 1.2 conversation, of course those are encrypted, nothing to see here, if the middlebox tampers with it that'll break people's web browsing. But actually the DH key agreement parameters for the session were in that optional extension and we aren't talking TLS 1.2 at all.
All this really means is operators that inspect SNI will now just block cloudflare-ech.com.
It’s a tug-o-war between cloud flare and the ISPs and network admins, essentially.
Any legitimate network operator who wants to avoid this for securiity reasons (i.e. for corporate managed devices) can just disable it by policy, assuming they aren't already using a decrypting TLS proxy.
Plus, there's an easier loophole than blocking ECH - block encrypted DNS. AFAIK most DNS over HTTPS/TLS implementations fall back to plaintext DNS if they can't make an encrypted connection. ECH's reliance on DNS privacy is its weak point; one that can't really be avoided right now.
Because very few websites bother to implement things like DNSSEC (and even fewer clients bother to validate it), the ISP DNS server can then fake all the ECH data it wants,
That was never reliable in the first place because of caching and non-compliant DNS servers, but:
EDNS has a DNS protocol extension that will send your IP subnet to the authoritative host even if the request has gone through various resolvers.
Not all DNS servers implement this (notably, Cloudflare doesn't). You can easily check if your DNS server sends your subnet along DNS requests: try to open https://archive.today/. If you see a Cloudflare error or a connection refused/500 error, this EDNS feature is not supported. archive.* intentionally sabotages DNS responses for servers that don't carry these extensions.
BGP anycast would be a solution that can route customer traffic to local datacenters without needing to fall back to DNS hacks and the many broken DNS intermediates.
I'm only half-joking though. ECH is already being widely enabled in clients, it will exceed Tor's adoption massively. Not as private, but (much more) usable.
