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

Encrypted Client Hello

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 219 posts

Re: Encrypted Client Hello

#71

Post by AnthonyMouse »

WorldMaker wrote: post #52
johnklos wrote: post #39

Earlier quoted context omitted.

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 one…

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

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

Re: Encrypted Client Hello

#72

Post by YeBanKo »

TrueDuality wrote: post #6
politelemon wrote: post #4

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

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 informati…

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

Re: Encrypted Client Hello

#73

Post by AnthonyMouse »

josephcsible wrote: post #67
AnthonyMouse wrote: post #60

Earlier quoted context omitted.

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

> 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 DHC…

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

Re: Encrypted Client Hello

#74

Post by YeBanKo »

AnthonyMouse wrote: post #56
TrueDuality wrote: post #6

Earlier quoted context omitted.

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 informati…

> 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 t…

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

Re: Encrypted Client Hello

#75

Post by andrewaylett »

dilyevsky wrote: post #16

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.

Re: Encrypted Client Hello

#76

Post by bscphil »

LinuxBender wrote: post #64
assassinator42 wrote: post #41

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…

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.

Re: Encrypted Client Hello

#77

Post by e12e »

politelemon wrote: post #4

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

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.

Re: Encrypted Client Hello

#78

Post by AnthonyMouse »

YeBanKo wrote: post #74
AnthonyMouse wrote: post #56

Earlier quoted context omitted.

> 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 t…

> 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 h…

it being the connection contents rather than the name, since Cloudflare actually needs the name to route the connection

Re: Encrypted Client Hello

#79

Post by tialaramex »

YeBanKo wrote: post #72
TrueDuality wrote: post #6

Earlier quoted context omitted.

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 informati…

> 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 thin…

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.

Re: Encrypted Client Hello

#80

Post by andrewaylett »

discardedrefuse wrote: post #15

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.

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.

Post reply on HN