Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New standards for a faster and more private Internet

blog.cloudflare.com

Post reply on HN
Print view View original

11–20 of 87 posts

Re: New standards for a faster and more private Internet

#11

Post by jeroenhd »

rkagerer wrote: post #9

ECH - if I understand correctly it's effective for sites hosted on big providers like Cloudflare, AWS, etc, but doesn't add much value when it comes to self-hosted domains or those on a dedicated server, as you'd still see traffic going to whatever IP and be able to infer from that which domain the user's browswer is talking to. I'm hoping someone can explain that I missed something. And while we're explaining things…

> When both are operated by the same company, how can you know they aren't colluding?

You don't. At best the client can check domain names and IP addresses, but that's hardly a guarantee.

To solve that problem, you can combine multiple parties. For example, you can use https://odoh1.surfdomeinen.nl/proxy as a proxy (operated by SURF [1]) to use the Cloudflare servers for lookup.

I think for ODoH to work well, we need a variety of companies hosting forwarding services. That could be ISPs, Google/Microsoft/etc. or some kind of non-profit.

[1]: https://www.surf.nl/en

Re: New standards for a faster and more private Internet

#12

Post by ekr____ »

rkagerer wrote: post #9

ECH - if I understand correctly it's effective for sites hosted on big providers like Cloudflare, AWS, etc, but doesn't add much value when it comes to self-hosted domains or those on a dedicated server, as you'd still see traffic going to whatever IP and be able to infer from that which domain the user's browswer is talking to. I'm hoping someone can explain that I missed something. And while we're explaining things…

Yes, that's correct about ECH. In general, there's no real way to conceal your browsing behavior if you are connecting to an IP address that isn't shared. So either you use ECH to something like Cloudflare or you connect to some proxy/VPN/etc. so that the local network can't see the final IP address.

Re: New standards for a faster and more private Internet

#13

Post by jeroenhd »

daveau wrote: post #10

re: ECH let the cat and mice game between deep packet inspection (DPI) vendors and the rest of the encrypted internet continue. it’ll be amusing to see what they come up with (inaccurate guessing game ai/ml “statistical analysis” is about all they’ve got left, especially against the large umbrella that is cloudflare). game on, grab your popcorn, it will be fun to watch.

There's a relatively simple and pain-free solution to legitimate DPI: blocking all requests that don't go through a proxy. Browsers will ignore some certificate restrictions if they detect manually installed TLS root certificates to make corporate networks work.

This approach won't work on apps like Facebook or Instagram, but I don't think there's a legitimate reason to permit-but-snoop on that sort of traffic anyway.

Re: New standards for a faster and more private Internet

#14

Post by ameliaquining »

java-man wrote: post #5

Does it mean ECH works only with the Cloudflare since their example ECH contains unencrypted outer layer client hello?

Right now, basically yes. No other major public clouds seem to support ECH yet, and ECH basically only works in public clouds; it can't hide your IP address, so it only provides privacy if you share your IP address with lots of other tenants.

Re: New standards for a faster and more private Internet

#16

Post by drdaeman »

aaomidi wrote: post #15

ECH is going to be huge for people in regressive countries. For example Iran.

Nah, they're just going to block the whole ECH handshake.

Idk about Iran, but Russia and China just block eSNI, QUIC and whatever their DPI firewalls can't really handle on the fly.

Re: New standards for a faster and more private Internet

#17

Post by candiddevmike »

daveau wrote: post #10

re: ECH let the cat and mice game between deep packet inspection (DPI) vendors and the rest of the encrypted internet continue. it’ll be amusing to see what they come up with (inaccurate guessing game ai/ml “statistical analysis” is about all they’ve got left, especially against the large umbrella that is cloudflare). game on, grab your popcorn, it will be fun to watch.

Passive DPI/web filtering is pretty much done at this point. There's no way to tell what domain you're connecting to with ECH without doing a MITM and breaking the PKI chain or adding private CAs everywhere.

Re: New standards for a faster and more private Internet

#18

Post by nialse »

Let me just stress that the effect of Zstandard on individual end-user latency is a rounding error. No user will ever go: “That was a quick loading web site. Must be Zstandard!”. The effect is solely Cloudflare having to spend x% less bandwidth to deliver the content, saving on their network and server resources.

Re: New standards for a faster and more private Internet

#19

Post by gwbas1c »

terrelln wrote: post #4
barbazoo wrote: post #2

> New standards for a faster and more private Internet > Zstandard I get "faster" but how does it make the internet "more private". The word "private" only shows up exactly once on that page, in the title.

I believe that the "more private" part is referencing the "Encrypted Client Hello (ECH)" section in the later part of the post.

The title of something should reflect the content. This is an article about a new compression format, and thus the title should say that.

Re: New standards for a faster and more private Internet

#20

Post by Rushsick »

drdaeman wrote: post #16
aaomidi wrote: post #15

ECH is going to be huge for people in regressive countries. For example Iran.

Nah, they're just going to block the whole ECH handshake. Idk about Iran, but Russia and China just block eSNI, QUIC and whatever their DPI firewalls can't really handle on the fly.

The idea is to make ECH too large of a target to make blocking it practical. If you block ECH you end up blocking access to a large portion of the internet in that region. It's why some major browsers have chosen to not gracefully fallback to non-ECH handshakes upon connection failure.
Post reply on HN