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

171–180 of 219 posts

Re: Encrypted Client Hello

#171

Post by nmadden »

msm_ wrote: post #136
Obscurity4340 wrote: post #125

Earlier quoted context omitted.

Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers? I legitimately don't understand why its not easier and in some bottom-line sense cheaper just to like double up your (classical) computing power. What is it about QC that's so damn sepcial when you could theoretically achieve the same maximal idealized output with a simple increase in classical…

>Can someone chime in with how quantum computers effectively at least double the output of traditional "classical" computers? In general: Quantum computers halve the search space, not speed, so for example quantum computer needs 2^128 operations to bruteforce 2^256 keys [1] In case of non quantum resistant algorithms (for example RSA or most other popular algorithms today): there are algorithms that offer exponential…

Quibble: Half of 2^256 is 2^255. Grover’s algorithm “square-roots” the search space.

Re: Encrypted Client Hello

#172

Post by AnthonyMouse »

josephcsible wrote: post #169
AnthonyMouse wrote: post #167

Earlier quoted context omitted.

> It doesn't matter much that your LAN itself is trustworthy if the only way out of it isn't. > Yes, you can do that, but it doesn't do anything to help with the problem that DoH solves. Well sure it is, because if you know the ISP isn't trustworthy, then you can have your own local DNS server encrypt the DNS traffic to the upstream DNS server of your choosing . > I want to live in a world in which you can have priva…

> Well sure it is, because if you know the ISP isn't trustworthy, then you can have your own local DNS server encrypt the DNS traffic to the upstream DNS server of your choosing . Isn't DoH exactly the way to "encrypt the DNS traffic"? > Something has to encrypt the DNS queries. Why is TLS/HTTPS any better than a VPN? Because with a VPN, you need a VPN endpoint that costs somebody money to run. With TLS/HTTPS, there…

> Isn't DoH exactly the way to "encrypt the DNS traffic"?

There are any number of ways to do it, the most relevant factor being that the user can choose which DNS server they want to trust, not which protocol you use.

> Because with a VPN, you need a VPN endpoint that costs somebody money to run. With TLS/HTTPS, there are no extra systems in the mix.

Someone is paying to run the DoH servers. You might also ask why they're doing so, for free, when that costs money.

> Don't domains hosting malware get seized and taken down too?

Malware often uses domains on foreign registries that are legally complicated to seize, so it only happens to the most serious offenders and can take a long time.

You also have vendor spyware which is not going to have its domain seized but is also not going to resort to Github pages for name resolution.

> I 100% agree with this. DoH only provides the former, though.

It doesn't. If legitimate applications are using DoH to a server outside of the device owner's control without providing an expedient way to make them all stop, that server can't be blocked without breaking too many things, and then malware running on the owner's device can use it without being blocked or monitored.

> Other than Firefox, what applications currently have Cloudflare hardcoded as their default DoH provider?

When someone is setting a bad precedent it's reasonable to be concerned about what happens when others follow suit.

Re: Encrypted Client Hello

#173

Post by growse »

mehlmao wrote: post #129
josephcsible wrote: post #93

Earlier quoted context omitted.

Just configure your endpoints to point at an ad blocking DoH server.

My partner has a Google Chromecast. Please tell me how I can configure it to use a DoH server I want, rather than the one dictated by Google. How about the video intercom systems in my apartment building? How can I configure them to use servers I trust rather than an unknown?

> My partner has a Google Chromecast. Please tell me how I can configure it to use a DoH server I want, rather than the one dictated by Google. How about the video intercom systems in my apartment building? How can I configure them to use servers I trust rather than an unknown?

Devices you don't control are under no obligation to follow your network's DNS policy, or even use published protocols for name resolution at all.

Re: Encrypted Client Hello

#174

Post by growse »

briHass wrote: post #140
josephcsible wrote: post #91

Earlier quoted context omitted.

There are ad-blocking DoH servers available. How is DoT any better than DoH in that respect?

Because, at least with plain ol UDP DNS, I can masquerade my adblocking DNS server to any IoT junk that ignores my DHCP provided DNS servers and uses its own hardcoded one. DoT is obviously immune to that, as is DoH, but at least for DoT, that seemes to never have become popular, likely due to the fear of aggressive firewalls not allowing that port.

> Because, at least with plain ol UDP DNS, I can masquerade my adblocking DNS server to any IoT junk that ignores my DHCP provided DNS servers and uses its own hardcoded one.

> DoT is obviously immune to that, as is DoH, but at least for DoT, that seemes to never have become popular, likely due to the fear of aggressive firewalls not allowing that port.

What happens when your junky hostile devices start doing name resolution over a protocol that doesn't look like DNS? Like, say, HTTPS!

Re: Encrypted Client Hello

#175

Post by growse »

josephcsible wrote: post #95
LinuxBender wrote: post #64

Earlier quoted context omitted.

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…

> The second way is to return a “no error no answer” or an NXDOMAIN response to queries made to the use-application-dns.net. This misfeature can't be removed from browsers soon enough. Its existence is totally contrary to DoH's threat model, since the people DoH is designed to protect you from are exactly the ones who can manipulate insecure DNS results for that domain.

It's just a network hint. Browsers are free to ignore (and I think Firefox has a toggle to ignore it).

Re: Encrypted Client Hello

#176

Post by minerva23 »

josephcsible wrote: post #50
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…

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

> No free country would tolerate tha

Which countries do you have in mind?

I know a lot of Americans talk that way about America, but America tolerates quite a bit of government censorship (DMCA/SLAP), privacy violations (NSA/TSA), and civil rights violations (prison slaves, war on drugs).

Re: Encrypted Client Hello

#177

Post by d-z-m »

YeBanKo wrote: post #151
d-z-m wrote: post #145

Earlier quoted context omitted.

> 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. The ISP doesn't see the DNS request, therefore added privacy(you are presumably contacting a DoH server whom you trust). ISPs can pretty much get away with blocking port 853 without much flak(fairly niche, not much use), but if customers' DoH queries to Cloudflare aren't getting ou…

DNS don’t serve regular web traffic, so all the request to DNS server can be classified as DNS request. So what does it add on top of DoT?

It's harder to block.

Re: Encrypted Client Hello

#178

Post by xorcist »

josephcsible wrote: post #88
xorcist wrote: post #62

Earlier quoted context omitted.

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

DoH doesn't make the Internet any more centralized. Just as with insecure DNS servers, anyone can run DoH servers too, and there are a lot of public ones: https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-av...

While it is indeed true that the design is such that there will always be fewer dns servers with the https based protocol, which also is a type of centralization, the point of the above perhaps too long comment is to highlight much more important issues.

Re: Encrypted Client Hello

#179

Post by 3np »

josephcsible wrote: post #166
jmprspret wrote: post #127

Earlier quoted context omitted.

> Why? Sane networks shouldn't block anything. Huh? What? Ever had to administer a corporate network for non-tech staff? Malware is everywhere. People are stupid. AND my assumption on a corporate network has always been that you have no expectation of privacy - its a work network, don't use it for personal stuff! Pretty simple.

If it's really a corporate network, then the company will own the endpoints and can do the inspection there.

Not meaningfully so with ECH, the whole point of this subthread.

Re: Encrypted Client Hello

#180

Post by tialaramex »

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…

> If we take away this last resort from governments, they would [...]

Appeasement doesn't work. Maybe it's easier to remember that if you're British and so you had to watch Chamberlain's "Peace for our time" news reel in history class. The British Prime Minister, Neville Chamberlain, negotiated a deal with rising star German Chancellor Adolf Hitler, you've heard of him. Hitler agreed that Germany wouldn't start a massive European war in exchange for the British turning a blind eye to smaller wars he'd already started.

You may never have heard of Chamberlain, because it turns out that piece of paper with Hitler's signature on it was worth precisely what you'd expect, and we needed an actual War Prime Minister soon enough.

Now, the argument for appeasement is that sure, it doesn't actually work but it buys time. This is wrong because your opponents have the same extra time and they know precisely what they're doing whereas you're expending resources pretending (even if you correctly believe the appeasement won't work) that appeasement works.

Post reply on HN