I see a lot of confusion here, probably Cloudflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1].
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.
> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key.
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.
I think the remark is because: MITM would allow them to spoof the DNS response entirely, so they can replace it with whatever key they want. Doesn't matter what level of security the key claims at that point, it's attacker-controlled and they can just read whatever you send next.
I think the DNS key is only for the handshake to provide the certificate for the actual key. Without a certificate from a CA for second part, all the spoofed DNS key would get is what website they were trying to visit.
Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers? I legitimately don't understand why its not easier and in some bottom-line sense cheaper just to like double up your (classical) computing power. What is it about QC that's so damn sepcial when you could theoretically achieve the same maximal idealized output with a simple increase in classical inputs?
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...
>Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers?
In general: Quantum computers halve the search space, not speed, so for example quantum computer needs 2^128 operations to bruteforce 2^256 keys [1]
In case of non quantum resistant algorithms (for example RSA or most other popular algorithms today): there are algorithms that offer exponential speedup, where even a slow (in terms of number of operations/second) quantum computer will easily outperform a classical comoputer
[1]: Grover's algorithm. I'm oversimplifying a bit.
I'm speaking in very abstract terms as a non-expert, but the critical distinction in this case is that prime factorisation (the basic underpinnings of RSA / similar encryption) is known to be an NP problem (more precisely - sub-exponential) for a classical computer but is polynomial for a quantum computer
To achieve the same computing power on a classical computer, it would need to be exponentially more powerful - this is because (abstracting heavily) the quantum computer can test all possible inputs to a function at once, where a classical computer must test them one at a time
Weren't some of these widespread conventions in some sense strategically designed or implemented in such a way as to ensure backdoors and/or contrived vulnerabillities? Something, something purposefully smaller key sizes or special "weaker" variables than was practicable or other trickery that always ostensibly has an economic or other seemingly justifiable underpinning but introduces unacceptable security compromises that arise later and predictably.
Historically there have been restrictions on key size (and bad algorithms) - to my knowledge, neither is currently the case: there is no known way to break a 2048-bit RSA key (although if there was, we probably wouldn't know about it)
Grover's algorithm is a general solution to the search problem. Given an arbitrary (computable) function f: X -> Y, and a desired value y in the codomain, find a value x such f(x) = y. For the sake of simplicity, assume that x is unique (although a Grover's algorithm can be extenef to not have this constraint).
Let N be the size of the domain X. On a classical computer, without any additional information, the optimal solution is to simply iterate through X trying inputs until you find the correct one. On average you will need to evaluate f on half the possible inputs, which is N/2. In the worst case, you need to try all N.
Using Grover's algorithm, you can solve the problem with only sqrt(N) invocations of f, which is a quadratic speed up compared with classical computers.
Applying this to encryption keys: for a keylenth of n, we have 2^n possible keys. Classically speaking, you would need to try decrypting (2^n)/2 = 2^(n-1) times. But with Grover's algorithm, you can find the correct key after decrypting judt sqrt(2^n) = 2^(n/2) times, which is the classical worst case for a key of half the length. Note that this is still exponential in the size of the key, so is not a fundamental game changer.
This has nothing to do with prime factoring or the discrete log problem. Those have even better quantum algorithms (Shor's) that can solve them in polynomial time, which would be a major game changer if they ever become practical.
Algorithms have been developed for quantum computers that could be potentially effective at breaking public key cryptosystems whose security relies on the difficulty of solving certain math problems on classical computers. In particular, the discrete logarithm problem and integer factorization of very large numbers: https://en.wikipedia.org/wiki/Shor%27s_algorithm.
There are no quantum computers large enough to even come close to attempting this, and there's a question about whether it's ever going to be physically possible to build a quantum computer large enough to actually attack something like a TLS key exchange in real time. Classical computers are equally as fast/faster at other tasks.
Is it a fair conjecture that in some sense there's an issue with cryptographer's trying to push the field in terms of the efficacy and robustness of encryption forward while "the government"s continually work all manner of trickery to hamper these efforts in subtle and not-so-subtle but gag-ordered-enforced ways?
I feel like there's this constant ridiculous pushback on any digital product or protocol or service being air-tight cryptographically and implementationally speaking when they can basically already build air-tight cases via parallel construction with the help of the infinite resources available upon (often not even) receipt of a warrant?
Its very strange. The obsession is always on completely neutering/compromising the technology and never on actually doing the damn police work they are enpowered to approach laterally like they did before typewriters and telephones/wire-taps or bending the providions of constitutions they swore to protect and enforce until its a simulacrum of its original concept.
Like, it always comes across as they feel that their entire case is lost if they can only prove something 5 different ways instead of 6. It wouldn't be so problematic if humans weren't so human and law enforcement wasn't emphatically staffed by humans who are liable to abuse things to maximize their money, power, and prestige and have the absolute or qualified immunity to get away with it at least once regardless of how it damages the targets of their misconduct.
>Like, it always comes across as they feel that their entire case is lost if they can only prove something 5 different ways instead of 6.
There are a lot of crimes these days without a complainant. The sale and consumption of illegal drugs for instance. Surveillance can be very important in discovering the crime in the first place.
It's like asking someone to help you with your diet and then becoming upset when they invade your privacy by looking in your kitchen cupboards and fridge. We have in a sense brought this on ourselves by passing laws intended to protect us from ourselves.
Did anybody ask governments to “help with diet” though? It feels more like governments in their ever expanding power struggle decided diets needed to be fixed even though nobody complained about them and then decided that the ends justify any means.
> 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.
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.
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).
We will almost certainly block ECH at my work, as we already block DoH. I expect any sane network to do the same.
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.
Huh? What? Ever had to administer a corporate network for non-tech staff? Malware is everywhere. People are stupid. AND my assumption on a corporate network has always been that you have no expectation of privacy - its a work network, don't use it for personal stuff! Pretty simple.
I don’t think morals factor in to the decision to allow / disallow traffic on a private network. That’s definitely morally neutral and to suggest otherwise is immoral.
ISPs are also private networks, unless operated by a government entity. And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.
> And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.
No. ISPs provide internet service to customers who pay them for it. The entire situation is different. The ISPs are under no obligation to break and inspect encrypted traffic. Owners and operators of home and corporate networks have an entirely different(and justifiable) set of concerns.
SNI monitoring is a reasonable compromise, and I think a healthy one: Your ISP doesn't need to deep inspect your traffic to Microsoft because it accepts that Microsoft is doing something reasonable with it. It allows delegating authority which at least gives a path for investigation or blocking if necessary without seeking an extreme amount of transient information.
I would say if ECH is implemented the correct response would unfortunately be to MITM it if too many providers implement it to just block it entirely. I suspect large companies won't force it to maintain a wide customer base, and again, any reasonable network operator should just block anyone who does.
ISPs absolutely have all sorts of regulatory needs and network performance reasons to classify traffic. It's an unpopular view, but it's reality. (And I would encourage you to investigate who pays the people telling you otherwise, before someone links Mike Masnick here.)
I think they mean malware. Ransomware for example. Nothing wrong about locking a network down in general. Work network doesn’t have to be an open, all things go, network just so employees can instagram. Heck, there are organizations with air-gaped networks for very good reasons.
Instagram on your phone while at work. Don’t expect privacy on managed work machines. You company can see your emails. They can install CA on your managed machine and MITM your https traffic.
I hate the trend of also managing personal devices. But I get that it’s a complicated subject.
I'll be worried when I hear the first case of an employee getting in trouble for doing something innocent on corpnet. Right now I assume they can see everything while using one of their devices or on their network but they never bug us about it. They seem mostly interested in stopping malware/leaks, which seems quite reasonable.
As the grandparent of this thread, I can definitely say I don't care about personal browsing on work computers. I consider that an HR issue (if it impacts their ability to do their job), not an IT issue. The ability to manage network traffic comes entirely from maintaining a secure and functional network.
MITM can't prevent leakage for a determined spy or insider trader. I worked at a bank, they blocked FB etc with a blacklist, but it was very easy to circumvent. Whitelist might work, but it would create too much management headache.
The problem is that what starts as a strong desire to conduct copyright infringement (or sure, some light personal web browsing on work computers) along with a dash of free speech extremism, has turned into a militant expectation of very handy passageways for actual crimes.
> 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.
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.
> 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.
Cloudflare adopts the similar predatory Google posture of "we really really care about your privacy - nobody else should spy on you but us". Creepy!!
They're going to resort to blocking IPs and not caring about collateral damage and force CDNs and anyone running multi tenant to turn the specific site targeted off or move them onto a separate pool of IPs that is easily blockable.
Do you think for a second anyone in power in China, Russia, or North Korea care if some random 20-year-old kid can access English-language sites or not?
> 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.
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.
No it can't. If it's in a browser, then extensions can still block it, and if it's in an app, then they could make it unblockable without needing DoH or ECH just by putting the trackers/ads/app telemetry on the same domain as the rest of what the app uses.
"I see a lot of confusion here, probably Clouflare should have included an explanation of how ECH works in TFA instead of referring to their other article[1]."
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":
"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."
Other people already explained that there's a bootstrap problem which prohibits "just encrypt 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.
Bootstrapping the encryption is a problem: until you've run the handshake, you don't have a key with which you could encrypt the handshake. And you don't want the key to live for too long, so folk are going to end up trying to use expired keys.
Between the article and the linked introduction, all of what you are looking for is explained.
How do you "just encrypt it"? Encryption in TLS starts after you have verified who you are talking to via the certificate, otherwise you might just be doing encryption with whoever happens to MITM you. However to do the verification, the server must know what domain you are actually trying to reach - hence the SNI. This is why there is the DNS side channel.
> If we take away this last resort from governments, they would [...]
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.
I'm not seeing it. It looks contradictory what they're saying.
> 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.
You're absolutely right, Cloudflare will still see it. That doesn't make this a bad improvement though. You don't have to use Cloudflare to support it, but it helps obscure which site is being visited by the nature of Cloudflare hosting so many different sites.
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.
> I still think DoH is hot garbage and the way it has been implemented across browsers is an atrocity.
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.
> I don't see why it's better than DoT or DoQ, except maybe a use case for censored countries.
This feels like saying "I don't see why we need oxygen in the atmosphere, except for people needing to breathe." Being able to overcome censorship is a huge win and is more than sufficient for DoH to be better than DoT, etc.
> 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.
The key making DoH still a net win in spite of that is that your ISP has the mapping from your source IP to your real-life identity, but DoH providers like CloudFlare don't.
Deployability is what matters. DoH had great deployability because everybody speaks HTTPS.
In my home, lots of technologies would work. I have static v4 and v6, I have complete control over the firewalls, I can do whatever I want. But at my mum's house, who knows what ports work and which protocols work over them and whether you can change any of that.
HTTPS definitely works though, because if it didn't her web browser wouldn't work and she'd yell at the ISP until they fixed it. So that's why DoH.
Everybody who speaks HTTPS speaks TLS and the existing DNS-over-TCP. DoT is just DNS-over-TCP tunneled inside TLS. And it can be on any port, not necessarily 853, could be even on 443. What is the point of wrapping it into http request?
> 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.
The ISP doesn't see the DNS request, therefore added privacy(you are presumably contacting a DoH server whom you trust). ISPs can pretty much get away with blocking port 853 without much flak(fairly niche, not much use), but if customers' DoH queries to Cloudflare aren't getting out, people are going to notice.
DoH makes the request look like a regular HTTPS request, therefore you'd need more sophisticated heuristics to block it.
If you contend that you can match the DoH SNI with a known DoH server and block that, fair enough. However, there's always another unknown DoH server you haven't blocked. Blocking DoT is trivial in comparison, because of its signature on the wire.
I agree that this is generally a good thing, and that DoH is an absolutely shitty thing, but I think the poster here was taking exception to this statement:
"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're absolutely right, Cloudflare will still see it. That doesn't make this a bad improvement though.
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.
> You can do something like ECH in a way that not even Cloudflare will see it
How is it possible for a Cloudflare to front a website, without knowing what the website it is. You browser is only supposed to do a handshake with a server with a certificate matching the domain, this make Cloudlare in charge of the cert. And Cloudflare needs to forward the traffic to a known location, so they __have__ to know the target host.
This is a power struggle, which I do not believe is really even on purpose by the people involved.
We used to have a decentralised Internet with a truly open and engineering-led garden of interoperable protocols. However during the past decade and a half we've seen a massive change. We find ourselves in a situation where only https matters. It's a catch 22 type of situation, where anything else better be able to tunnel over it, otherwise many users will be left out since it's all that is supported, because it's what others tunnel over.
While this happened, the browser organizations grew politically strong and now controls not only the public key infrastructure that underpins https but also standardization of https itself.
The only exception to this is dns. Together with ip itself it follows the open meritocratic process that gave us decentralised planet wide internetworking. Unfortunately, it is closely tied with the domain name system, which is controlled by a parallel organization which isn't as open and meritocratic.
So basically we have three stakeholders of political value in the Internet ecosystem today. Us proponents of open and permissionless internetworks closely align with one, one is a gray area, and one is a conglomerate of private companies.
It is really healthy for the Internet if Mozilla, Microsoft and Cloudflare took control over dns resolving on a wide scale? Even apart from the obvious privacy issues?
They may mean well, but it logically follows that when dns is centralized among a few actors, they also will have an unproportionally large say in the evolution of the system. They could even tack on some extra top domains or other extensions that they could resolve. All in good faith of course. But that would, in time, bring over any remaining users of the old decentralized system.
It's not as if similar things hasn't happened before, in other contexts. So, yes, I will be one of the holdouts and keep resolving my own dns queries. It's not harder than "apt-get install unbound". It's the way the distributed domain name database was designed to work, and for good reason.
While it is indeed true that the design is such that there will always be fewer dns servers with the https based protocol, which also is a type of centralization, the point of the above perhaps too long comment is to highlight much more important issues.
Right, so barely technologically DoH is better than DNS as it's encrypted?
Since anyone can run a DoH server as well, how is that "politically" worse than DNS?
EDIT: Right, so I think I figured it otu: the issue is with locked DoH DNS servers where one can't MITM them anymore due to encryption and not being able to fake the server certificates.
Nothing is wrong with DoH. When people complain about it, it's generally because they like being able to successfully perform the kind of attacks it's meant to prevent, e.g., censorship and surveillance of traffic between endpoints they own neither of, just because the traffic passes through their network.
I agree with you, but the counterargument that'll be made against you is "you should be doing that on the endpoints".
That counterargument ignores the fact that you can be the owner of an endpoint but not be permitted, by manufacturer's policy, to control the software running inside. That's what you get for purchasing a proprietary device.
So, as the network operator and owner of the endpoints in the world of DoH (and pinned certificates), you end up being left with the decision to "vote with your wallet" and simply not purchase devices that don't afford you influence on name resolution (or whatever functionality we're talking about)
The counterargument goes on to say that the manufacturers of these sealed-box devices can functionally do this today anyway simply by implementing their proprietary name resolution (content delivery, etc) protocol.
My partner has a Google Chromecast. Please tell me how I can configure it to use a DoH server I want, rather than the one dictated by Google. How about the video intercom systems in my apartment building? How can I configure them to use servers I trust rather than an unknown?
> My partner has a Google Chromecast. Please tell me how I can configure it to use a DoH server I want, rather than the one dictated by Google. How about the video intercom systems in my apartment building? How can I configure them to use servers I trust rather than an unknown?
Devices you don't control are under no obligation to follow your network's DNS policy, or even use published protocols for name resolution at all.
Yeah, this entire topic is strange to me. Is the crux of the issue that some devices come with unchangeable DNS servers, so when these are configured to be DoH then they can't be MITMed?
It takes our control over our networks away from us and gives it to random applications, to Trojans, to viruses, to adware purveyors, to advertisers.
It makes the assertion that because SOME of us don't know how to change our DNS servers, they (Mozilla, Cloudflare, other proponents of DoH) need to take control away from us and need to send our DNS lookups to, usually, them.
The justifications are ridiculous, but the harms introduced by DoH are much, much worse than the thing they're trying to say makes DoH useful.
> It takes our control over our networks away from us
Taking control away from the owner of networks is a good thing. Control is supposed to reside with the owner of endpoints. To see why, imagine if your ISP started to MITM all of your connections that went over their network.
> don't know how to change our DNS servers
It's not a case of "don't know how". It's a case of "can't, because even if you change the setting, $evil_isp will hijack the queries anyway".
> Taking control away from the owner of networks is a good thing. Control is supposed to reside with the owner of endpoints. To see why, imagine if your ISP started to MITM all of your connections that went over their network.
What you need for this is some kind of encrypted DNS. What you don't need is for it to be implemented in the way DoH commonly does it.
What you should have is a router, which hands itself out as the DNS server via DHCP, takes the client's plaintext DNS request and does an encrypted query -- ideally directly to the authoritative servers for that domain, but at least to something of your choosing. Or, you configure your device to do this itself for every application using the system DNS. These all work fine, because the device owner can reasonably change them -- you configure it in one place for every application or your whole LAN at once.
The problem with DoH is that it puts it into each individual application, and then its infeasible for the device owner to change it because it's a million settings in a million places and some applications don't support changing it at all. Worse, you get evil applications where the endpoint device is the thing controlled by Evil Corp and the local network is the thing the device owner is using to block spyware. At which point "the network" needs to be able to block this or malware and evil IoS garbage can operate with impunity.
The claimed workaround is that browsers try to resolve a particular name with the system DNS and then turn of DoH if it resolves in a particular way, but now you're back to this:
> It's a case of "can't, because even if you change the setting, $evil_isp will hijack the queries anyway".
Because then $evil_isp can just resolve that name in that way to go back to doing the MITM. At which point you've lost any benefit of the device doing this against a truly malicious ISP, or it becomes an excuse to remove this "feature" and then the device owner can't do it either.
> browsers try to resolve a particular name with the system DNS and then turn of DoH if it resolves in a particular way
I agree that's the wrong way to let DoH be turned off, exactly for the reason you describe. It should only be possible for DoH to be disabled by, e.g., the local user manually going into settings or by Group Policy.
> What you should have is a router, which hands itself out as the DNS server via DHCP
The problem with that is that I don't trust the DHCP server of whatever network I'm on to not be trying to censor or surveil me.
> I agree that's the wrong way to let DoH be turned off, exactly for the reason you describe. It should only be possible for DoH to be disabled by, e.g., the local user manually going into settings or by Group Policy.
DHCP is group policy for network configuration. If you're connecting to a network where you don't trust the DHCP server then don't use DHCP for DNS or use a VPN.
> The problem with that is that I don't trust the DHCP server of whatever network I'm on to not be trying to censor or surveil me.
The application default needs to be the system DNS and the device default needs to be DHCP so the device owner can feasibly change them. Then anyone for whom this doesn't work can change it merely by changing one system-wide setting, with the easiest way being to use a VPN and their DNS -- something that should be done on untrusted networks regardless.
The real Group Policy only affects computers that a local administrator explicitly joined to a domain. DHCP shouldn't have any such control since it's not trusted.
> If you're connecting to a network where you don't trust the DHCP server then don't use DHCP for DNS
But that's exactly what people are complaining that Firefox enabled.
> The application default needs to be the system DNS and the device default needs to be DHCP so the device owner can feasibly change them.
Once every common end-user OS has default-on DoH, then that would be better, but until then, I think individual programs using DoH on their own is a net benefit.
> The real Group Policy only affects computers that a local administrator explicitly joined to a domain. DHCP shouldn't have any such control since it's not trusted.
DHCP only affects computers that a local administrator configures to use DHCP. The fact that it's on by default is why turning it off is a defect -- when you want to change the DNS on all the computers on your LAN, you change the one the DHCP server gives out. If applications start ignoring this then there is no reasonable alternative way to do it.
Consider that the reason you want it to be the default is the friction to users of changing the default. Now you see the problem if someone wants to change it from Cloudflare -- only now it's even worse if you remove DHCP as a way to change it.
> But that's exactly what people are complaining that Firefox enabled.
Because it's for the user to enable, and in particular to choose which DNS server to use instead, not Mozilla.
> Once every common end-user OS has default-on DoH, then that would be better, but until then, I think individual programs using DoH on their own is a net benefit.
What you need is for consumer routers to do this rather than Mozilla. Have them give out their own address as the DNS via DHCP and then support DoH themselves.
The reason endpoint devices don't do this by default, and shouldn't, is where do they get the address of the DoH server to use, if not DHCP?
> DHCP only affects computers that a local administrator configures to use DHCP. The fact that it's on by default is why turning it off is a defect -- when you want to change the DNS on all the computers on your LAN, you change the one the DHCP server gives out. If applications start ignoring this then there is no other existing way to do it.
With Group Policy, the computer's administrator chooses a specific domain to trust to receive policies from. With DHCP, whatever random network the computer connects to can send whatever settings it wants. This is why it's okay for Group Policy to control security-sensitive settings but not for DHCP to. Imagine if the coffee shop's DHCP server sent an option that meant "the client should open these ports in its firewall". Would you want your computer to respect that?
> Because it's for the user to enable, and choose which DNS to use instead, not Mozilla.
Why is DHCP-provided DNS okay being the default, but Mozilla-provided DNS not? The user didn't choose the former either.
> What you need is for consumer routers to do this rather than Mozilla. Have them give out their own address as the DNS via DHCP and then support DoH themselves.
The problem with the router doing it is that clients can't trust the router isn't owned by someone trying to spy on them.
> The reason endpoint devices don't do this by default, and shouldn't, is where do they get the address of the DoH server to use, if not DHCP?
From a hardcoded default, e.g., Cloudflare, Google, Mullvad, or Quad9. Consider how most computers have a hardcoded default list of NTP servers to use rather than relying on getting that from DHCP.
> With Group Policy, the computer's administrator chooses a specific domain to trust to receive policies from. With DHCP, whatever random network the computer connects to can send whatever settings it wants. This is why it's okay for Group Policy to control security-sensitive settings but not for DHCP to.
Computers don't connect to random networks. The user chooses to, and has the ability to not use the DNS from DHCP for any given network.
> Imagine if the coffee shop's DHCP server sent an option that meant "the client should open these ports in its firewall". Would you want your computer to respect that?
It already does this. The client gets its gateway via DHCP, which is not only the device that typically firewalls local networks from the rest of the internet, it's the device that can see and modify all of your traffic.
> Why is DHCP-provided DNS okay being the default, but Mozilla-provided DNS not? The user didn't choose the former either.
Because of what is necessary to change it. There has to be some default, but it should be possible for the user to change it all in one place for their entire LAN or device.
> The problem with the router doing it is that clients can't trust the router isn't owned by someone trying to spy on them.
They certainly can when it's their own router, and they can manually configure a DNS server of their choosing when it isn't.
Meanwhile, how can the user trust that Cloudflare isn't trying to spy on them?
> From a hardcoded default, e.g., Cloudflare, Google, Mullvad, or Quad9. Consider how most computers have a hardcoded default list of NTP servers to use rather than relying on getting that from DHCP.
NTP servers see that your computer wants to know what time it is. DNS servers see all kinds of privacy-sensitive information, so centralizing this in any way is inherently dangerous and so is making it more difficult for the user to change the default.
It takes control away from the owner of networks, even when we're the owner of those networks. Should DoH start to become more common, blocking it will become a Sisyphean task.
It takes control away from the owner of endpoints. Sure, you can go and change the settings in Firefox to turn off DoH after they've turned it on without asking and without telling us, but what happens when applications and Trojans start doing DoH lookups, skipping our system's configured DNS? So yes, your statement about control residing with the endpoints is correct, but DoH removes control, doesn't add it.
For the case of "can't, because even if you change the setting, $evil_isp will hijack the queries anyway", that's FUD. There are many, many better ways to deal with evil ISPs.
Encouraging the world to send all of their DNS lookups to a centralized entity like Cloudflare (who, by every right, are precisely in a position to be an evil ISP) is such an incredibly shortsighted idea that I have to think that you haven't thought out the implications of a world where DoH is dominant.
If you care to learn, consider things without DoH: you can edit your hosts file. You can choose your DNS servers. You can run a local recursive resolving DNS server. You can block ads and advertisingware using your DNS server and/or something like Pihole. You can block all DNS queries to the outside world on your network so that they all go through your own resolvers.
Next, consider a world where DoH is commonplace: you have no control over DNS lookups on your own system. Your only choice is to not run binaries that might do things you don't like. Want to block ads or adware, or adult sites, or conspiracy sites, or any of a number of other things on the Windows system that your child uses? Now Edge doesn't let you. Want to block the Trojans and phishing sites that Google serves through their ad network? Chrome doesn't let you. "Just don't run binaries that do that" is one heck of an ask for people who don't know how to set their own DNS or who have an evil ISP.
You can block common DoH servers, until Cloudflare puts them on the same address as the endpoints for their millions of hosting customers. But what happens when apps do DoH lookups using random Amazon AWS or Google Cloud servers? How do you block them? Do you block ALL https?
You see, you'd give up freedom, and have everyone else give up their freedom, for some abstract "safety" from ISPs that use your DNS data. You'd apply a shitty fix for 1% of the people to 100% of the people, rather than create tools for the 1% to circumvent their evil ISPs.
The fact that you'd choose this makes me think that either you want big, evil companies like Cloudflare to win, or you really don't understand the issues.
Just like this article above does a good job explaining the lack of security in the cloud, we really could use a good article explaining how completely inane the idea of DoH is.
> but what happens when applications and Trojans start doing DoH lookups, skipping our system's configured DNS?
Exfiltration has always been a problem. But it's not a good reason to make MITM possible.
Network control should not give control over endpoints any degree more than is necessary to deliver packets from point A to B. We can't trust them with more.
> [...] Now Edge doesn't let you.
That's blatantly false for normal endpoints though. Be it an AV or parental controls, an endpoint administration will have that ability to intercept.
If an endpoint doesn't let you do thay then to be honest, you've already lost the battle. Even simple HTTPS is not really filterable.
> Just like this article above does a good job explaining the lack of security in the cloud, we really could use a good article explaining how completely inane the idea of DoH is.
What is actually inane is the amount of implicit trust and control given to networks right now. Your network might be a nice wonderland, but many aren't.
People own their networks when they're not out in public. Again, solving for a problem with public networks by forcing shortcomings on to all networks is shortsighted and ill conceived.
"But it's not a good reason to make MITM possible" is disingenuous. Avoiding DoH doesn't make MITM possible, just as adding DoH doesn't save us from MITM. It does, though, save apps / Trojans from MITM, particularly when we're the ones who want to be in the middle :P
"That's blatantly false for normal endpoints though. Be it an AV or parental controls, an endpoint administration will have that ability to intercept."
Go ahead and tell me how to remove Edge, or how to have Windows open links in other browsers, without involving third party software that forces this, then tell me how "endpoint administration" is something we can expect of people who can't set their own DNS (or who have evil ISPs and can't set up any of a number of other ways to circumvent said evil ISPs).
You didn't address the real meat of the issue: Why is avoiding one issue - ISPs tracking DNS - worth all the bad things that come with it? The only explanation that makes sense to me is that it's worth it to companies that want to control as much as they can, like Cloudflare.
"What is actually inane is the amount of implicit trust and control given to networks right now." So instead of teaching people how and encouraging them to make their networks better, you'd rather divest some of that trust to companies like Cloudflare, and to every application / Trojan writer? Right - because the amount of data collection in software isn't a problem at all. We just need to trust them, and they'll do right by us.
You've made my point for me that you, and other apologists for DoH, haven't really thought things through, have you?
> People own their networks when they're not out in public. Again, solving for a problem with public networks by forcing shortcomings on to all networks is shortsighted and ill conceived.
It's not just being out in public. Even when you're home, you're still at the mercy of your ISP.
> Go ahead and tell me how to remove Edge, or how to have Windows open links in other browsers
What does preventing use of Edge have to do with DoH?
> You didn't address the real meat of the issue: Why is avoiding one issue - ISPs tracking DNS - worth all the bad things that come with it?
You've yet to convincingly point out a single bad thing that actually comes from DoH.
> So instead of teaching people how and encouraging them to make their networks better, you'd rather divest some of that trust to companies like Cloudflare, and to every application / Trojan writer?
You can't make public Wi-Fi or your ISP's network better no matter how knowledgeable you are.
"Even when you're home, you're still at the mercy of your ISP." No, I'm not. If you think I am, then you don't understand networking.
"What does preventing use of Edge have to do with DoH?" If you can't have basic control of programs on your own computer, tell me how you're going to control programs' use of DoH.
"You've yet to convincingly point out a single bad thing that actually comes from DoH." I've named many: we lose the ability to block ads, adware, Trojan CaC, spyware, et cetera. We lose the privacy of our own DNS lookups. Your suggestion seems disingenuous.
"You can't make public Wi-Fi or your ISP's network better no matter how knowledgeable you are." No - YOU can't or don't want to, because you don't understand networking. People who want to can, though, and this is what I'd encourage, instead of enshittifying the Internet by believing companies like Cloudflare when they tell us our ISPs suck and we should just trust them instead.
> "Even when you're home, you're still at the mercy of your ISP." No, I'm not. If you think I am, then you don't understand networking.
If your ISP dropped all packets on port 53 that contained a response for example.com, how would you circumvent that and learn its IP otherwise?
> "What does preventing use of Edge have to do with DoH?" If you can't have basic control of programs on your own computer, tell me how you're going to control programs' use of DoH.
Name a single program (other than unambiguous malware that nobody would ever be okay with being installed at all) that always uses DoH regardless of any configuration by a local administrator.
> "You've yet to convincingly point out a single bad thing that actually comes from DoH." I've named many: we lose the ability to block ads, adware, Trojan CaC, spyware, et cetera. We lose the privacy of our own DNS lookups. Your suggestion seems disingenuous.
There are DoH resolvers that do ad and malware blocking. Moving DNS from cleartext to an encrypted protocol is certainly not losing privacy.
> "You can't make public Wi-Fi or your ISP's network better no matter how knowledgeable you are." No - YOU can't or don't want to, because you don't understand networking. People who want to can, though, and this is what I'd encourage, instead of enshittifying the Internet by believing companies like Cloudflare when they tell us our ISPs suck and we should just trust them instead.
How are you proposing that people make other people's networks better? And are you saying that Americans' ISPs don't suck?
You answer questions by answering what you feel like and diverting, not by addressing what's relevant to the discussion. I'm not going to answer things in good faith when you're just playing dumb.
I'm fairly certain you're trolling. Do you do this with friends and family, too? Just so you know, people aren't agreeing with you just because they decide to stop engaging with you.
I like the fact that your attempts to derail are all here, plain as day, for anyone to see, because people knowing that DoH is a big scam to grab private data about them is important.
> People own their networks when they're not out in public.
People rent their networks from one, maybe two area options. The consumer networks want to completely control router hardware these days and these days charge extra rental fees for owned hardware instead of rented hardware. (It's fascinating that they can legally get away with that.) Some of the biggest consumer networks have already proven they are happy to use this hardware control to inject additional ads into customers' networks for a paltry amount of additional revenue.
You are correct that people should have networks that they own and trust at home. You may have missed that they don't and consumers have lost that battle. (You may also be underestimating just how much time people spend on devices "out in public". The mobile device has become the most common device for a lot of users. For some users the only device.)
> every application / Trojan writer
They've always had that power.
Applications have never been forced to use OS/network-configured DNS. DNS is an absurdly simple protocol that doesn't even have encryption by default. OS firewalls might block sockets to DNS ports by default, but there are ways to tunnel over other ports plus tools like UPnP given enough user trust.
DoH is a standardized port tunnel but that doesn't mean that unstandardized ones never existed before. Trojans/viruses have been doing weird things to avoid DNS for decades. DoH doesn't make them that much easier.
DoH isn't great and it is a shame that for privacy and control it's a big ugly trade-off/compromise from ideals. It's useful for some people. There are definitely unanswered questions in terms of which big corporation truly cares about privacy. I've seen my monopolist consumer ISP inject ads against my wishes and do change the DNS on my home (owned) routers (that I pay extra for each month despite owning my own hardware because of owning my own hardware). I don't always know what to think about Cloudflare's massive PR engine of how much they claim to value privacy, but so far I've never seen them inject an ad where one doesn't belong nor have I seen ad revenue make a splash in their quarterly reports. They don't seem to be an ad company. (Yet?)
Trust is hard and we all have different threat models. I don't blame you for distrusting Cloudflare. I have direct evidence for distrusting my current ISP and indirect evidence for distrusting most consumer ISPs I've encountered, despite being paying customers. There's no free lunch and there's no right answer, just a lot of "least wrong" answers. DoH isn't the right answer objectively. But DoH can be a "least wrong" for some users. Just as trying to be the MITM in networks you own is quite wrong from a security standpoint (once you've got one MITM it becomes harder to trust that there isn't a second one) but may be the "least wrong" answer for some users including maybe you.
Trust is hard, yes. Cloudflare might not be going for the low hanging fruit such as injecting ads, but they clearly want to be a monopoly around whom the Internet recentralizes.
Moving DNS from an ISP, who we pay and with whom we have legal contracts, to a company that does things, supposedly, for altruistic reasons, with whom we do NOT have contracts, doesn't fix anything. It makes things worse. The solution is to remove DNS from your ISP and run it yourself, or use a not-for-profit that isn't trying to become a monopoly, that isn't in a position to have its data syphoned off by the NSA, that doesn't knowingly and willingly host spammers, phishers and scammers.
How about we don't trust ISPs AND we don't trust Cloudflare?
BTW - I have to flatly disagree with your suggestion that, "once you've got one MITM it becomes harder to trust that there isn't a second one". That's ridiculous. I can check and verify things to a much greater degree by running my own network. Also, I never said anything about MITM my own network. I want to run my own DNS and block DNS to the rest of the Internet. That's not MITM.
The least wrong thing is to not replace something that MIGHT be shitty with something that MIGHT also be shitty, but might also open you to new problems and security issues. The idea that it MIGHT be less shitty isn't a good enough reason for DoH.
> The solution is to remove DNS from your ISP and run it yourself
This doesn't work because if you run your own recursive DNS server, it will make insecure requests to all of the authoritative servers, and so your ISP can hijack them all. And DNSSEC will keep you from getting sent to the wrong domain, but won't help you figure out the right domain.
> I want to run my own DNS and block DNS to the rest of the Internet.
Your private recursive DNS server, of course, has to send requests to the rest of the internet; you don't want to block those. They don't have to be plaintext, unless the authoritative server in question only talks plaintext.
Of course, and it's obviously easier to configure a single recursive resolver to prefer encryption wherever possible than it is to try to configure each client (or in the case of DoH, each program) to do opportunistic encryption.
The point is that these requests don't go to my ISP's DNS servers.
And for the other people who're making up unrealistic scenarios such as the ISP trying to MITM all DNS, not just queries they answer, there are many forms of tunneling that can be used such as VPNs. It's still easier to do one solution for the whole network than individual solutions for each client (or each application, for DoH).
> People rent their networks from one, maybe two area options.
That's not the LAN.
> The consumer networks want to completely control router hardware these days and these days charge extra rental fees for owned hardware instead of rented hardware. (It's fascinating that they can legally get away with that.)
You can put your own router behind theirs. It's ridiculous for them to make you do that but nothing actually stops you.
> You may also be underestimating just how much time people spend on devices "out in public".
For which anyone can use a VPN.
> Applications have never been forced to use OS/network-configured DNS. DNS is an absurdly simple protocol that doesn't even have encryption by default. OS firewalls might block sockets to DNS ports by default, but there are ways to tunnel over other ports plus tools like UPnP given enough user trust.
Your local network can intercept ordinary DNS queries to any server and redirect them to your own. To work around this, a piece of malware would have to contact some custom server on a different port to do a name lookup -- but where does it look up that server's IP address? Hard-coding the IP address allows the malware's lookup server to be blocked.
But if centralized DoH servers become too popular to block because blocking them breaks too many legitimate applications, now the malware can use them and the user can't block them.
> I don't always know what to think about Cloudflare's massive PR engine of how much they claim to value privacy, but so far I've never seen them inject an ad where one doesn't belong nor have I seen ad revenue make a splash in their quarterly reports. They don't seem to be an ad company.
The question is, what are they doing with the data they collect?
> There's no free lunch and there's no right answer, just a lot of "least wrong" answers.
There is already a "least wrong" answer: Use a VPN you trust and use your VPN's DNS or run your own. VPNs have plenty of competition, and you can set up your own on any hosting provider, which also have plenty of competition.
This is basically the same thing as having Cloudflare do it over TLS, except that it's not centralized and remains in the control of the user, so is better.
It doesn't matter much that your LAN itself is trustworthy if the only way out of it isn't.
> You can put your own router behind theirs. It's ridiculous for them to make you do that but nothing actually stops you.
Yes, you can do that, but it doesn't do anything to help with the problem that DoH solves.
> For which anyone can use a VPN.
I want to live in a world in which you can have privacy without having to be on a VPN 24/7.
> To work around this, a piece of malware would have to contact some custom server on a different port to do a name lookup -- but where does it look up that server's IP address? Hard-coding the IP address allows the malware's lookup server to be blocked.
Couldn't it host a file with the IP on a service like Dropbox or GitHub Pages? People aren't likely to block them at the firewall.
> But if centralized DoH servers become too popular to block because blocking them breaks too many legitimate applications, now the malware can use them and the user can't block them.
Isn't this basically "privacy for computer programs is bad because malware benefits from it", which is wrong for the same reason that "privacy for people is bad because criminals benefit from it"?
> The question is, what are they doing with the data they collect?
What's your ISP doing with all of the data they collect from your insecure DNS queries? And if you're concerned about Cloudflare in particular, then just use some other DoH provider.
> There is already a "least wrong" answer: Use a VPN you trust and use your VPN's DNS or run your own. VPNs have plenty of competition, and you can set up your own on any hosting provider, which also have plenty of competition.
> This is basically the same thing as having Cloudflare do it over TLS, except that it's not centralized and remains in the control of the user, so is better.
> It doesn't matter much that your LAN itself is trustworthy if the only way out of it isn't.
> Yes, you can do that, but it doesn't do anything to help with the problem that DoH solves.
Well sure it is, because if you know the ISP isn't trustworthy, then you can have your own local DNS server encrypt the DNS traffic to the upstream DNS server of your choosing.
> I want to live in a world in which you can have privacy without having to be on a VPN 24/7.
Something has to encrypt the DNS queries. Why is TLS/HTTPS any better than a VPN?
> Couldn't it host a file with the IP on a service like Dropbox or GitHub Pages? People aren't likely to block them at the firewall.
Those services will take down the page when it's hosting malware.
> Isn't this basically "privacy for computer programs is bad because malware benefits from it", which is wrong for the same reason that "privacy for people is bad because criminals benefit from it"?
The question is, privacy from who? Privacy from governments and corporations is good. Privacy from the device owner is bad.
> What's your ISP doing with all of the data they collect from your insecure DNS queries?
Nothing, when you configure your LAN or device to encrypt them.
> And if you're concerned about Cloudflare in particular, then just use some other DoH provider.
Hard-coding Cloudflare in multiple applications on multiple devices makes it arduous to do this, which is the entire criticism.
> Well sure it is, because if you know the ISP isn't trustworthy, then you can have your own local DNS server encrypt the DNS traffic to the upstream DNS server of your choosing.
Isn't DoH exactly the way to "encrypt the DNS traffic"?
> Something has to encrypt the DNS queries. Why is TLS/HTTPS any better than a VPN?
Because with a VPN, you need a VPN endpoint that costs somebody money to run. With TLS/HTTPS, there are no extra systems in the mix.
> Those services will take down the page when it's hosting malware.
Don't domains hosting malware get seized and taken down too?
> The question is, privacy from who? Privacy from governments and corporations is good. Privacy from the device owner is bad.
I 100% agree with this. DoH only provides the former, though.
> Nothing, when you configure your LAN or device to encrypt them.
Again, isn't DoH exactly the way to encrypt them?
> Hard-coding Cloudflare in multiple applications on multiple devices makes it arduous to do this, which is the entire criticism.
Other than Firefox, what applications currently have Cloudflare hardcoded as their default DoH provider?
> Isn't DoH exactly the way to "encrypt the DNS traffic"?
There are any number of ways to do it, the most relevant factor being that the user can choose which DNS server they want to trust, not which protocol you use.
> Because with a VPN, you need a VPN endpoint that costs somebody money to run. With TLS/HTTPS, there are no extra systems in the mix.
Someone is paying to run the DoH servers. You might also ask why they're doing so, for free, when that costs money.
> Don't domains hosting malware get seized and taken down too?
Malware often uses domains on foreign registries that are legally complicated to seize, so it only happens to the most serious offenders and can take a long time.
You also have vendor spyware which is not going to have its domain seized but is also not going to resort to Github pages for name resolution.
> I 100% agree with this. DoH only provides the former, though.
It doesn't. If legitimate applications are using DoH to a server outside of the device owner's control without providing an expedient way to make them all stop, that server can't be blocked without breaking too many things, and then malware running on the owner's device can use it without being blocked or monitored.
> Other than Firefox, what applications currently have Cloudflare hardcoded as their default DoH provider?
When someone is setting a bad precedent it's reasonable to be concerned about what happens when others follow suit.
As jeremiads go, this is golden. I for one and persuaded and am grateful you wrote it.
I hadn't considered before that DoH effectively takes an avenue away from people who want to block advertising and trackers. This makes it a fiercely unpleasant thing working against users.
Personally, I'm switching to DNS over TLS instead.
Because, at least with plain ol UDP DNS, I can masquerade my adblocking DNS server to any IoT junk that ignores my DHCP provided DNS servers and uses its own hardcoded one.
DoT is obviously immune to that, as is DoH, but at least for DoT, that seemes to never have become popular, likely due to the fear of aggressive firewalls not allowing that port.
> Because, at least with plain ol UDP DNS, I can masquerade my adblocking DNS server to any IoT junk that ignores my DHCP provided DNS servers and uses its own hardcoded one.
> DoT is obviously immune to that, as is DoH, but at least for DoT, that seemes to never have become popular, likely due to the fear of aggressive firewalls not allowing that port.
What happens when your junky hostile devices start doing name resolution over a protocol that doesn't look like DNS? Like, say, HTTPS!
> It takes control away from the owner of networks, even when we're the owner of those networks.
My point is that even when you are the owner of a network, you shouldn't have control of traffic on it between endpoints that you don't own either of.
> what happens when applications and Trojans start doing DoH lookups, skipping our system's configured DNS?
The Trojans could just hardcode the IP instead, so blocking DoH wouldn't magically guarantee you could catch them with DNS.
> So yes, your statement about control residing with the endpoints is correct, but DoH removes control, doesn't add it.
Which programs specifically don't let the user disable DoH? If none, then how does its presence remove control?
> For the case of "can't, because even if you change the setting, $evil_isp will hijack the queries anyway", that's FUD. There are many, many better ways to deal with evil ISPs.
Such as? How would you solve the specific problem of an evil ISP hijacking DNS?
> centralized entity like Cloudflare (who, by every right, are precisely in a position to be an evil ISP)
ISPs tend to have regional monopolies, but DoH servers don't. If Cloudflare becomes evil, you can just switch to some other DoH server.
> If you care to learn, consider things without DoH: you can edit your hosts file. You can choose your DNS servers. You can run a local recursive resolving DNS server. You can block ads and advertisingware using your DNS server and/or something like Pihole. You can block all DNS queries to the outside world on your network so that they all go through your own resolvers.
All but the last thing is still possible with DoH, and it's a good thing that it breaks the last thing, since doing that would affect other people's endpoints too.
> Next, consider a world where DoH is commonplace: you have no control over DNS lookups on your own system.
How do you figure? DoH is still configurable.
> Your only choice is to not run binaries that might do things you don't like.
I already don't.
> Want to block ads or adware, or adult sites, or conspiracy sites, or any of a number of other things on the Windows system that your child uses? Now Edge doesn't let you. Want to block the Trojans and phishing sites that Google serves through their ad network? Chrome doesn't let you.
Those are still easy: just point at a DoH server that does those blocks, the same way you'd point at an insecure DNS server that does them today.
> You can block common DoH servers, until Cloudflare puts them on the same address as the endpoints for their millions of hosting customers. But what happens when apps do DoH lookups using random Amazon AWS or Google Cloud servers? How do you block them? Do you block ALL https?
It's a good thing that network-level blocking of DoH is hard.
> You see, you'd give up freedom, and have everyone else give up their freedom, for some abstract "safety" from ISPs that use your DNS data. You'd apply a shitty fix for 1% of the people to 100% of the people, rather than create tools for the 1% to circumvent their evil ISPs.
What freedom am I giving up? What harm does DoH do to regular people?
You're not arguing in good faith. You're suggesting that me controlling my own network, and people controlling their own networks, is bad ("even when you are the owner of a network, you shouldn't have control of traffic on it between endpoints that you don't own either of").
You're suggesting that applications and Trojans have the "right" to be free from my control, on my network, on my machines. Wow. What a take!
You're saying that all programs, Trojans included, will allow us to configure DoH. Again, a pretty crazy take, and completely, unambiguously wrong.
"What freedom am I giving up? What harm does DoH do to regular people?"
You clearly don't care about freedom, since you actively want to send your DNS to some third party. But you'd have me give up my freedom to control what goes on on my network because some ISPs track DNS, and instead of addressing that, you're for the idea of normalizing a protocol that removes my freedom and puts it in the hands of application / Trojan makers.
It harms regular people because it exfiltrates private information that they don't know about. Someone installs Firefox (very common) and doesn't know about DoH (also very common). Now their DNS lookups are all going to Cloudflare. We have no reason to trust Cloudflare (we do have plenty of reasons to not trust them, though).
But the point is that these regular people DON'T KNOW and haven't agreed to have their DNS data shared with Cloudflare. This has all sorts of negative implications that I'm sure you can't see.
> You're suggesting that me controlling my own network, and people controlling their own networks, is bad ("even when you are the owner of a network, you shouldn't have control of traffic on it between endpoints that you don't own either of").
Should your ISP be allowed to censor what you can see on the Internet? Remember they own the network that all of your traffic flows through.
> You're suggesting that applications and Trojans have the "right" to be free from my control, on my network, on my machines. Wow. What a take!
I'm not arguing that anything on your machines should be free from your control. I'm specifically saying that traffic passing through your network but not from or to one of your machines should be free from your control.
> You're saying that all programs, Trojans included, will allow us to configure DoH. Again, a pretty crazy take, and completely, unambiguously wrong.
I meant all legitimate programs do. Trojans obviously do whatever they want, and that was the case even before DoH existed.
> You clearly don't care about freedom, since you actively want to send your DNS to some third party.
You're always sending your DNS requests to some third parties. The only question is which.
> But you'd have me give up my freedom to control what goes on on my network because some ISPs track DNS, and instead of addressing that, you're for the idea of normalizing a protocol that removes my freedom and puts it in the hands of application / Trojan makers.
I disagree that "my freedom to control what goes on on my network" is a freedom that should be protected. For an extreme example, consider that someone complaining "they took away my freedom to own slaves" is obviously in the wrong. As I've said before, you should only have any control of traffic for which one of the endpoints is yours.
> It harms regular people because it exfiltrates private information that they don't know about. Someone installs Firefox (very common) and doesn't know about DoH (also very common). Now their DNS lookups are all going to Cloudflare. We have no reason to trust Cloudflare (we do have plenty of reasons to not trust them, though).
Most American ISPs are way less trustworthy than Cloudflare, and that's where almost everyone's DNS would be going otherwise.
> But the point is that these regular people DON'T KNOW and haven't agreed to have their DNS data shared with Cloudflare. This has all sorts of negative implications that I'm sure you can't see.
Do regular people even know what DNS is? Did they agree that their ISP could see their insecure DNS?
I can't tell if you're a troll or if you're really just not understanding things.
My network is not my ISP's network. My ISP can't censor me. I advocate for people to have control over their own networks and to take control from their ISPs.
I'm not sure why you want to conflate my network with what my ISP provides, but anyone thinking that clearly doesn't understand how things work (or is just trying to be a troll).
Likewise, "all legitimate" programs will allow DoH configuration? Really? Have you TRIED to do simple, common sense things in Windows like use another browser? Obviously this suggestion is ridiculous.
Please tell me how traffic would pass through my network that isn't from or to one of my machines. Guests? That's a bullshit reason to suggest I shouldn't have control over my network.
"You're always sending your DNS requests to some third parties." No, I'm not. I run my own DNSSEC recursive resolvers.
At this point, I have to believe you're a troll.
"consider that someone complaining "they took away my freedom to own slaves"" is also trolling. If you think packets and programs are equivalent to humans, you're... broken. But at this point I really have to wonder what you expect to get out of trolling. You're just making yourself look dumb at this point.
Right, but traffic from your computers passes through both.
> My ISP can't censor me.
Either you and your ISP can both do network-level censorship, or neither can.
> I'm not sure why you want to conflate my network with what my ISP provides, but anyone thinking that clearly doesn't understand how things work (or is just trying to be a troll).
Because your endpoints' traffic goes through both, and they both have the same ability to censor.
> Likewise, "all legitimate" programs will allow DoH configuration? Really? Have you TRIED to do simple, common sense things in Windows like use another browser? Obviously this suggestion is ridiculous.
Again, what does being able to change the default browser on Windows have to do with whether you can configure DoH?
> Please tell me how traffic would pass through my network that isn't from or to one of my machines. Guests? That's a bullshit reason to suggest I shouldn't have control over my network.
Guest computers on your network are in the exact same position as your router on your ISP's network.
> "You're always sending your DNS requests to some third parties." No, I'm not. I run my own DNSSEC recursive resolvers.
Even if you don't count the servers your recursive resolver talks to as third parties, your ISP can still see all of your recursive resolver's traffic, and just drop the responses for domains it doesn't want you visiting, even with DNSSEC.
> "consider that someone complaining "they took away my freedom to own slaves"" is also trolling. If you think packets and programs are equivalent to humans, you're... broken.
I don't think they're equivalent at all. My point was just that just because you can't do a certain thing anymore doesn't necessarily mean freedom has been lost.
> 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.
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.
The point of efforts like this is exactly to make selective blocking infeasible. This will force the bad guys to choose between blocking nothing and blocking everything, and with the exception of North Korea, most aren't willing to do the latter.
Cloudflare sees it here because the TLS is closed at Cloudflare end. ECH main point is the prevent traffic snooping by ISPs. In India a lot of websites are blocked due to gov regulations. Those blocks are implemented via the inspection of the ClientHello packet to know which website are being accessed. Hopefully this will prevent such blocks.
Not sure if it was edited, but TFA states near the top now:
> 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.
When I visit a more local website only my ISP and the site's ISP will see the domain name. With default browser setting some, probably overseas, entity that I didn't trust and didn't choose gets my request, ignoring my system configuration and without asking.
You are missing the big picture. Of course CF still sees it - they need to route your request somewhere (remember why SNI is a thing at all and we don't just use DNS) and you are after all choosing to talk to a CF server. But it means not everyone on your network that happens to see your traffic can trivially see you are visiting pornhub.com
> 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.
If I understand this right, it is basically "cloudfare will appear like a huge web server for anybody watching".
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.
In this case, the centralization is an advantage for privacy, depending on how you look. Basically, no one can guess who you are trying to connect to by looking at the packets (modulo fingerprinting…).
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.
The real catch is centralisation makes surveillance way easier. When all communications are centralised to CF, it's a piece of cake for a government to eavesdrop by going directly after CF. It gives way more information than SNI and if they want to do business in your country they won't have other choice than complying.
Agreed. its like if only 2 people uses tor then even though its encrypted and anon, you still know who used tor and can identity those 2 people. Now if a large majority uses tor, then anonymity becomes easier.
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.
You are correct, this is how a CDN typically works. Cloudflare know who you are and got full deciphered observability (can also tamper) for all your traffic with the websites using their services. ECH is not meant to change this fact, you still trust Cloudflare with all communications to their customers.
This is going to make it even more of a pain to do egress filtering on networks/systems we administer.
I want to be able to allow list sites with dynamic IPs. The existing solutions for doing this by examining SNI are already often bypassable by forging the SNI (looking at you, AWS Network Firewall).
CF explain how to do this here [1]. Have your local DNS resolvers filter the HTTPS type of DNS queries on your DNS servers. One example from Microsoft [2]. Unbound would probably need a patch though a work-around could be an iptables string filter or u32 filter for the record type. There is a DNS module [3] for iptables but it is not part of any default installations AFAIK.
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.
This only works because browser vendors have taken the totally bullshit approach of "you're only allowed to use ECH if you have DoH enabled", even though they're really unrelated technologies. Related Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1500289
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.
> The second way is to return a “no error no answer” or an NXDOMAIN response to queries made to the use-application-dns.net.
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.
That DNS module for IPTables actually looks to be a bit outdated and is missing the type HTTPS as far as I can tell so maybe a request to the people at nlnetlabs to add options for query types to block in Unbound DNS may be useful.
You're supposed to do that kind of filtering on the endpoint. If it's possible anywhere else, then it could be used to censor other people's computers.
I'm afraid you only take into account private use.
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.
If you own all of the endpoints, then it is indeed morally okay for you to do network-level filtering. The problem is that if we design network protocols so it's possible for you to do that, then it will also be possible for people to do network-level filtering that affects endpoints they don't own.
How do you propose that it be possible for you to do that to things like your smart TV without it being possible for you to do that to other people's computers?
Sorry for the plug but DiscrimiNAT Firewall actively prevents ECH [1] from flowing through and cannot be bypassed with SNI forging either [2]. Also has a great 'discovery' mode and CLI tooling to figure out that allowlist on an on-going basis.
If you're doing any SNI filtering, you can validate the SNI with the certificate passed in the ServerHello (which most tools skip, because that's computationally expensive in comparison). This involves reconstructing message streams as well, of course. You'll also need to figure out how to deal with 1RTT (probably block it).
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.
> 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.
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.
If I'm reading this right, blocking this would result in a denial of service rather than a security downgrade. And Cloudflare is so large that blocking all of its hosted sites would effectively look like a partial internet outage. That might not bother state actors, but any ISP in a free country that willingly did this would be so overwhelmed by customer service requests that it wouldn't be worth it.
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.
In many cases you don't even need to block DoH. Many implementations (Chrome/Edge/I believe Windows itself) will try to use the ISPs DoH servers by default if available, and switch to an alternative if the user chooses to do so.
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,
It seems like the same result could easily be achieved by widespread Domain Fronting support (e.g set sni to cloudflare-sekrit.com and Host: header to the actual domain). Can someone explain why this wasn't adopted more widely (I know CF, for example, disabled theirs)?
That relies on the user knowing that they can trust the certificate they use as the front in lieu of the certificate for the domain they actually want. Which is sub-optimal from a security point of view -- unless you complete a handshake with a valid certificate for the domain you're actually visiting, how do you know that the server you're talking to actually has a valid certificate?
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.
This explanation makes sense, thanks! I mean other than the fact you’re still trusting cloudflare not to mess with the data since it’s terminating ssl =) but i agree that makes this somewhat cleaner from client perspective
As a visitor to the site, I need to decide whether or not to trust the site's operator. As the operator of a site, I need to work out which vendors I can trust. Cloudflare takes the role of a vendor here, it's exceptionally common for vendors to terminate SSL. And it's quite challenging to run a CDN without access to the plain-text request.
Cloudflare at least offers mutual TLS from the edge to your origin, I've yet to persuade either of the other major CDN vendors I've worked with that they should offer that feature. They've also pioneered the rather nifty ability to terminate TLS on a node that doesn't actually have direct access to the certificate it's using, which I'd quite like for some other use-cases.
None of which is to say that you shouldn't have any concerns about Cloudflare, but on the other hand if you're that worried then at least the server operators using Cloudflare are giving you a heads-up that you maybe don't want to trust their judgement?
For whatever reason, Domain Fronting is considered more of an attack behavior, used by red teamers and penetration testers. Doubling down on that behavior likely didn't seem as appealing from a PR perspective.
i find the OP rather amusing--one of the earlier incidents during my time at Cloudflare (circa 2015) was dealing with prolific domain fronting, where IIRC some third-party proxy tool had set something up to the effect of "send SNI query for unblocked site on CF network, send HTTP Host for blocked site" automatically. this was ultimately blocked less because it was strictly undesirable and more because it resulted in some sort of cache poisoning problem. the unintended use started serving those proxy hack results to regular, non-domain fronting requests for whatever reason, which is obviously bad--you want the CDN to serve normal requests correctly, so you squash abnormal requests that work on their own, but cause cascading problems for other not abnormal requests.
many years down the road this is now an actual (with the problem cases handled) feature!
I believe CF and others buckled under pressure from major websites which didn't want to be used as fronts for other website's traffic. ECH fixes this because individual sites get to opt-in to using it.
... and this is exactly what will happen to cloudflare-ech.com.
I'm really disappointed with how the ECH spec panned out. It's almost like "make sure middleboxes and GFW can block this" was a hard requirement. They should've made the handshake look like a session resumption (i.e. pre-shared key), since those aren't required to send a server name.
If I'm understanding the draft correctly, I think the webserver you're hosting your sites on would need it implemented as it requires private keys and ECH configuration. In the example of nginx since it uses openssl, openssl would need to implement it. I found an issue on their Github but it's still open: https://github.com/openssl/openssl/issues/7482
ECH can be enabled depending on the Terminating TLS server used. (not sure which one implements it now)
But you are right in the sense its used for multiple sites to one IP.
Essentially ECH is protection for SNI, ALPN, which are plaintext in non-ECH.
Naive question, In 2023 how does DNS-over-HTTP (DoH) affect things like the Cisco Distributed Director / F5 3-DNS where DNS is used to control which datacenters customer traffic is going to? Is this still a technology smaller sites can use?
> where DNS is used to control which datacenters customer traffic is going to
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.
ECH is still not working with Cloudflare in all regions. If someone from Cloudflare see this, please let us know the status of ECH rollout in all regions.
Just like Dropbox is an improvement over FTP with SVN?
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.
But without having to set up Tor or suffering any of the downsides of using it. And if you do want all the privacy of Tor, this doesn't stop you from using it.
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.
This is very wise of them. Rolling out new network features is always going to be something of an experiment, no matter how confident you are that the feature meets all the standards and works in all browsers and all OSes. You never know what weird stuff is going to be out there that will screw things up. Back when they first tried to roll out TLS 1.3 there were tons of problems due to buggy middleboxes in corporate networks that couldn't conceive of a new TLS protocol. Thankfully they worked around it, but it probably sucked for the guinea pigs.
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.
You're likely thinking of the point when the TLS 1.3 core protocol design was finished, but they were experimenting to understand deployability. This is long before the TLS 1.3 protocol your browser uses today was finished, and that is about half a year earlier than RFC 8446 was published. So any "guinea pigs" in this experiment know what they're getting into, likely people explicitly working on, or in a group tasked with supporting, TLS 1.3. This is like that Windows 95 era but instead of buying random Windows software in a Best Buy to check it works on Win95 before you ship it, you are raising Purchase Orders to buy the "Best Security Office SSL Protection Plus" or whatever to check what it does with your prototype TLS 1.3 stack.
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.
I feel like this is only possible because Cloudflare is already so huge. If this becomes widely adopted, anyone who wants to offer "private" access to their site will have to move through Cloudflare. This can't be good.
A lot of shared hosting providers would also be able to implement this. Bringing the benefits of ECH's anti-snooping to many end-users outside of CloudFlare.
Individual servers hosting one single website won't benefit much though. Unless you do encrypted split-DNS, I guess.
That's not something Cloudflare decided, though. It's just a fundamental limitation on how the Internet works. The destination IP needs to be visible to intermediate nodes so that they know how to get it there, so the only way to get this kind of privacy is for lots of services to be hosted behind the same destination IP. And keep in mind that it's not Cloudflare exclusive. Any similar service that does large-scale name-based virtual hosting will also give you the same privacy benefit with this.
Thanks for the info. This feels a little better. I can still envision only a handful of "providers" becoming the defacto gatekeepers to a private web. I'm gonna have to give this some more thought though.
I'm absolutely not offering to implement it, but it does seem like one ought to be able to proxy the inner hello to the origin so the owner of the shared IP address doesn't actually get to inspect the content of the TLS stream.
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.
Any CDN or shared hosting provider could implement this same standard. The only way it's truly useless is if a web site has its own IP address / small set of IP addresses.
(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.)
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...