31 ms·

Encrypted Client Hello

243 points by cosmosgenius 3y ago

makeworld 3y ago
If I host my website on a VPS, is ECH possible? Seems like it's only useful when IP addresses are shared across a bunch of sites.
- politelemon 3y ago
  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 https://github.com/openssl/openssl/issues/7482
- cosmosgenius 3y ago
  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.
- dilyevsky 3y ago
  Yes, but if you use dedicated IP it is kind of like pointless. If you use shared IP of your VPS provider (or Cloudflare) then yes fr
ploum 3y ago
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. Did I miss something?
- cryptonym 3y ago
  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.
- Aissen 3y ago
  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.
  - cryptonym 3y ago
    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.
- josephcsible 3y ago
  It's not making the Web any more centralized. It's a silver lining we get due to how centralized it already is.
  - Racing0461 3y ago
    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.
politelemon 3y ago
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.
- cosmosgenius 3y ago
  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.
- TrueDuality 3y ago
  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.
Al0neStar 3y ago
Everytime someone mentions Cloudflare, i think about this article [0]. [0] https://blog.cr.yp.to/20230609-turboboost.html https://blog.cr.yp.to/20230609-turboboost.html
discardedrefuse 3y ago
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.
- galadran 3y ago
  Any provider can deploy ECH, it's standardized at the IETF. Cloudflare are just first.
  - discardedrefuse 3y ago
    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.
- Avamander 3y ago
  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.
  - discardedrefuse 3y ago
    Thanks for the info.
- josephcsible 3y ago
  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.
dilyevsky 3y ago
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)?
- jeffmcjunkin 3y ago
  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.
- galadran 3y ago
  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.
  - dilyevsky 3y ago
    You could just as easily make df opt-in. Another way is to use “fake” cloudflare-df.com sni just like they are doing with cloudflare-ech.com outer sni
    - josephcsible 3y ago
      A designated domain for domain fronting is useless because it would immediately get added to every middlebox's list of blocked domains.
      - KirillPanov 3y ago
        ... 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.
supriyo-biswas 3y ago
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. [1] https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/ [2] https://www.article19.org/resources/france-proposed-internet-bill-threatens-online-speech/ https://www.article19.org/resources/france-proposed-internet... [3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
- josephcsible 3y ago
  > 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. No free country would tolerate that.
gray_charger 3y ago
This just sounds like a less private Tor.
- Avamander 3y ago
  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.
- josephcsible 3y ago
  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.
Thoreandan 3y ago
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?
- josephcsible 3y ago
  How would it affect those things any more than devices' use of 8.8.8.8 for insecure DNS (which is already quite common) does?
- jeroenhd 3y ago
  > 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/ 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.
assassinator42 3y ago
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).
- josephcsible 3y ago
  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.
  - folmar 3y ago
    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.
    - josephcsible 3y ago
      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.
  - jbombadil 3y ago
    I see your point, but on my network I want that ability. I want to have my tv connect to YouTube, but not phone Sony/Samsung/whoever. I want to be able to setup a pihole to block adds independently of the browser/device being used.
    - josephcsible 3y ago
      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?
effnorwood 3y ago
[dead]
elashri 3y ago
It is surprising that if you are on the free plan then “Enabled by default for Free zones.”
- KirillPanov 3y ago
  Actually it's kinda smart. 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.
- profmonocle 3y ago
  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.
  - tialaramex 3y ago
    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.
yardstick 3y ago
> 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.
- profmonocle 3y ago
  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.
  - jeroenhd 3y ago
    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,
imaginenoruz 3y ago
[flagged]
deleted 3y ago
[deleted]
vinay_ys 3y ago
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.
moderation 3y ago
To my knowledge the only browser testing site for ECH - https://defo.ie/ech-check.php https://defo.ie/ech-check.php
cloudyq 3y ago
[dead]

243 points by cosmosgenius 3y ago

If I host my website on a VPS, is ECH possible? Seems like it's only useful when IP addresses are shared across a bunch of sites.

politelemon 3y ago
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 https://github.com/openssl/openssl/issues/7482
cosmosgenius 3y ago
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.
dilyevsky 3y ago
Yes, but if you use dedicated IP it is kind of like pointless. If you use shared IP of your VPS provider (or Cloudflare) then yes fr

ploum 3y ago

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. Did I miss something?

cryptonym 3y ago
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.
Aissen 3y ago
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.
- cryptonym 3y ago
  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.
josephcsible 3y ago
It's not making the Web any more centralized. It's a silver lining we get due to how centralized it already is.
- Racing0461 3y ago
  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.

politelemon 3y ago

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.

cosmosgenius 3y ago
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.
TrueDuality 3y ago
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.

Al0neStar 3y ago

Everytime someone mentions Cloudflare, i think about this article [0]. [0] https://blog.cr.yp.to/20230609-turboboost.html https://blog.cr.yp.to/20230609-turboboost.html

discardedrefuse 3y ago

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.

galadran 3y ago
Any provider can deploy ECH, it's standardized at the IETF. Cloudflare are just first.
- discardedrefuse 3y ago
  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.
Avamander 3y ago
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.
- discardedrefuse 3y ago
  Thanks for the info.
josephcsible 3y ago
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.

dilyevsky 3y ago

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)?

jeffmcjunkin 3y ago
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.
galadran 3y ago
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.
- dilyevsky 3y ago
  You could just as easily make df opt-in. Another way is to use “fake” cloudflare-df.com sni just like they are doing with cloudflare-ech.com outer sni
  - josephcsible 3y ago
    A designated domain for domain fronting is useless because it would immediately get added to every middlebox's list of blocked domains.
    - KirillPanov 3y ago
      ... 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.

supriyo-biswas 3y ago

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. [1] https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/ [2] https://www.article19.org/resources/france-proposed-internet-bill-threatens-online-speech/ https://www.article19.org/resources/france-proposed-internet... [3] https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...

josephcsible 3y ago
> 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. No free country would tolerate that.

gray_charger 3y ago

This just sounds like a less private Tor.

Avamander 3y ago
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.
josephcsible 3y ago
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.

Thoreandan 3y ago

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?

josephcsible 3y ago
How would it affect those things any more than devices' use of 8.8.8.8 for insecure DNS (which is already quite common) does?
jeroenhd 3y ago
> 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/ 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.

assassinator42 3y ago

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).

josephcsible 3y ago
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.
- folmar 3y ago
  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.
  - josephcsible 3y ago
    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.
- jbombadil 3y ago
  I see your point, but on my network I want that ability. I want to have my tv connect to YouTube, but not phone Sony/Samsung/whoever. I want to be able to setup a pihole to block adds independently of the browser/device being used.
  - josephcsible 3y ago
    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?

effnorwood 3y ago

[dead]

elashri 3y ago

It is surprising that if you are on the free plan then “Enabled by default for Free zones.”

KirillPanov 3y ago
Actually it's kinda smart. 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.
profmonocle 3y ago
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.
- tialaramex 3y ago
  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.

yardstick 3y ago

> 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.

profmonocle 3y ago
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.
- jeroenhd 3y ago
  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,

imaginenoruz 3y ago

[flagged]

deleted 3y ago

[deleted]

vinay_ys 3y ago

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.

moderation 3y ago

To my knowledge the only browser testing site for ECH - https://defo.ie/ech-check.php https://defo.ie/ech-check.php

cloudyq 3y ago

[dead]