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

61–70 of 219 posts

Re: Encrypted Client Hello

#61

Post by johnklos »

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…

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.

Re: Encrypted Client Hello

#62

Post by xorcist »

kreetx wrote: post #13
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…

What is wrong with DoH?

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.

Re: Encrypted Client Hello

#63

Post by josephcsible »

johnklos wrote: post #55
josephcsible wrote: post #48

Earlier quoted context omitted.

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

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

> My network is not my ISP's network.

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.

Re: Encrypted Client Hello

#64

Post by LinuxBender »

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

[1] - https://developers.cloudflare.com/ssl/edge-certificates/ech/

[2] - https://learn.microsoft.com/en-us/windows-server/networking/...

[3] - https://github.com/mimuret/iptables-ext-dns

Re: Encrypted Client Hello

#65

Post by stefan_ »

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

Re: Encrypted Client Hello

#66

Post by stefan_ »

silverwind wrote: post #53
supriyo-biswas wrote: post #25

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…

Why is DNS required to encrypt a TLS handshake? Why are there two SNIs in a ClientHello? ECH seems like a overengineered implementation when they could just have released TLS 1.4 which encrypts that section of the handshake.

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.

Re: Encrypted Client Hello

#67

Post by josephcsible »

AnthonyMouse wrote: post #60
josephcsible wrote: post #29

Earlier quoted context omitted.

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

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

Re: Encrypted Client Hello

#68

Post by andrewaylett »

silverwind wrote: post #53
supriyo-biswas wrote: post #25

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…

Why is DNS required to encrypt a TLS handshake? Why are there two SNIs in a ClientHello? ECH seems like a overengineered implementation when they could just have released TLS 1.4 which encrypts that section of the handshake.

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.

Re: Encrypted Client Hello

#69

Post by fivre »

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

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!

Re: Encrypted Client Hello

#70

Post by nfoz »

josephcsible wrote: post #44
kreetx wrote: post #13

Earlier quoted context omitted.

What is wrong with DoH?

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.

Are you familiar with https://pi-hole.net/ ?

In my house I want DNS resolution to be performed by my own DNS resolver (https://github.com/NLnetLabs/unbound), after I block ad domains.

DoH circumvents that.

Post reply on HN