i may be wrong here, but if i remember correctly, in ech, essentially our first communication is done with some central server (which as of now is mostly cloudflare) and then they make some connection with target server, and then a channel is established between us and target. my google-fu brought me this , which is basically this only
I am unfamiliar with QUIC, and quick search basically tells it is kinda like multilane highway for udp.
If I have to compare, (not a network engineer or a person who has studied networking, to me anything beyond the simple protocols seems magic), QUIC seems like a techt which is only used after you have made connection with target, so its implementation is google independent (they seem to be lead developers for this). Whereas in ECH, cloudflare are the primary devs, but also the holder for the public keys (someone else can also be the holder, but i dont know of any other provider currently, maybe my lack of knowledge here)
Essentially just an extension of your point that implementation is lacking
essentially our first communication is done with some central server
No, the first communication is made with your DNS server to fetch the key for encryption from an HTTPS record. If a record with key is found it is used to encrypt the Client Hello, otherwise it falls back to the unencrypted variant.
Cloudflare is not involved, unless you are hosting your domain through Cloudflare of course.
I am unfamiliar with QUIC, and quick search basically tells it is kinda like multilane highway for udp.
QUIC is primarily used for HTTP/3. The protocol was engineered and proposed by Google, same as with ECH and Cloudflare.
I doubt it. Today there is a huge trend towards censorship in the world. And ECH is exactly what a censor would not want. It is already blocked in Russia after Cloudflare enabled it by default and I would expect it to be blocked in the west “for anti-piracy reasons” very soon.
Intensions do not metter in this case. It can be used for that and that’s enough.
If you block any connections that use ECH (by blocking cloudflare-ech for example) users will have no choice but to fallback to unencrypted CH.
I want ECH (Encrypted Client Hello) to finally take off. https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello
Implementation is still lacking unfortunately.
for me, currently the problem is over reliance on Cloudflare, which is yet another big tech company
In what sense? ECH does not rely on Cloudflare anymore than QUIC relies on Google.
i may be wrong here, but if i remember correctly, in ech, essentially our first communication is done with some central server (which as of now is mostly cloudflare) and then they make some connection with target server, and then a channel is established between us and target. my google-fu brought me this , which is basically this only
https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3C9ceBTx5AQXu8tS0lgzdF/55ea89f5a56843db15296b2b47f7b1c2/image3-17.png (https://blog.cloudflare.com/encrypted-client-hello/)
I am unfamiliar with QUIC, and quick search basically tells it is kinda like multilane highway for udp.
If I have to compare, (not a network engineer or a person who has studied networking, to me anything beyond the simple protocols seems magic), QUIC seems like a techt which is only used after you have made connection with target, so its implementation is google independent (they seem to be lead developers for this). Whereas in ECH, cloudflare are the primary devs, but also the holder for the public keys (someone else can also be the holder, but i dont know of any other provider currently, maybe my lack of knowledge here)
Essentially just an extension of your point that implementation is lacking
No, the first communication is made with your DNS server to fetch the key for encryption from an HTTPS record. If a record with key is found it is used to encrypt the Client Hello, otherwise it falls back to the unencrypted variant.
Cloudflare is not involved, unless you are hosting your domain through Cloudflare of course.
QUIC is primarily used for HTTP/3. The protocol was engineered and proposed by Google, same as with ECH and Cloudflare.
I doubt it. Today there is a huge trend towards censorship in the world. And ECH is exactly what a censor would not want. It is already blocked in Russia after Cloudflare enabled it by default and I would expect it to be blocked in the west “for anti-piracy reasons” very soon.
ECH is intended for privacy, not for circumventing censorship.
If the next TLS version enforces ECH, plaintext SNI will die out at some point on its own.
Intensions do not metter in this case. It can be used for that and that’s enough. If you block any connections that use ECH (by blocking cloudflare-ech for example) users will have no choice but to fallback to unencrypted CH.