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

131–140 of 219 posts

Re: Encrypted Client Hello

#131

Post by jiggawatts »

josephcsible wrote: post #112
ceilingcat0 wrote: post #110

Earlier quoted context omitted.

They're going to resort to blocking IPs and not caring about collateral damage and force CDNs and anyone running multi tenant to turn the specific site targeted off or move them onto a separate pool of IPs that is easily blockable.

The hope is that the CDNs explicitly refuse to do that, so that the collateral damage leads to pressure that forces the censor to relent.

Narrator: they didn't relent.

Do you think for a second anyone in power in China, Russia, or North Korea care if some random 20-year-old kid can access English-language sites or not?

Re: Encrypted Client Hello

#132

Post by tick_tock_tick »

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

Most of Europe will.

Re: Encrypted Client Hello

#133

Post by infinityio »

Obscurity4340 wrote: post #125
ignoramous wrote: post #124

Earlier quoted context omitted.

> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic . Don't think tr…

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…

I'm speaking in very abstract terms as a non-expert, but the critical distinction in this case is that prime factorisation (the basic underpinnings of RSA / similar encryption) is known to be an NP problem (more precisely - sub-exponential) for a classical computer but is polynomial for a quantum computer

To achieve the same computing power on a classical computer, it would need to be exponentially more powerful - this is because (abstracting heavily) the quantum computer can test all possible inputs to a function at once, where a classical computer must test them one at a time

Re: Encrypted Client Hello

#134

Post by missingrib »

Obscurity4340 wrote: post #125
ignoramous wrote: post #124

Earlier quoted context omitted.

> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic . Don't think tr…

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…

Algorithms have been developed for quantum computers that could be potentially effective at breaking public key cryptosystems whose security relies on the difficulty of solving certain math problems on classical computers. In particular, the discrete logarithm problem and integer factorization of very large numbers: https://en.wikipedia.org/wiki/Shor%27s_algorithm.

There are no quantum computers large enough to even come close to attempting this, and there's a question about whether it's ever going to be physically possible to build a quantum computer large enough to actually attack something like a TLS key exchange in real time. Classical computers are equally as fast/faster at other tasks.

Re: Encrypted Client Hello

#135

Post by ocdtrekkie »

catiopatio wrote: post #130
ocdtrekkie wrote: post #118

Earlier quoted context omitted.

SNI monitoring is a reasonable compromise, and I think a healthy one: Your ISP doesn't need to deep inspect your traffic to Microsoft because it accepts that Microsoft is doing something reasonable with it. It allows delegating authority which at least gives a path for investigation or blocking if necessary without seeking an extreme amount of transient information. I would say if ECH is implemented the correct respo…

> SNI monitoring is a reasonable compromise, and I think a healthy one No, it’s not. ISPs have no right to know who I am speaking to or why.

I mean you have no right to use their networks either. You generally agree to terms as a condition of use of said networks.

Re: Encrypted Client Hello

#136

Post by msm_ »

Obscurity4340 wrote: post #125
ignoramous wrote: post #124

Earlier quoted context omitted.

> plaintext DNS is avoided in order to prevent a MITM on the ClientHelloInner key. Is MiTM possible unless the attacker is in possession of a sufficiently advanced quantum computer? What's published as HTTPS/SVCB record is the public part of the key. Afaik, DNSSEC isn't even a requirement for zones publishing HTTPS/SVCB ECH records? > Doing so prevents ISPs and governments from analyzing your traffic . Don't think tr…

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 speedup, where even a slow (in terms of number of operations/second) quantum computer will easily outperform a classical comoputer

[1]: Grover's algorithm. I'm oversimplifying a bit.

Re: Encrypted Client Hello

#137

Post by d-z-m »

ocdtrekkie wrote: post #116
josephcsible wrote: post #115

Earlier quoted context omitted.

I didn't mean private networks. I meant the ISPs that do that.

ISPs are also private networks, unless operated by a government entity. And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.

> And I would absolutely uphold the same expectation from an ISP as an organizational or personal network.

No. ISPs provide internet service to customers who pay them for it. The entire situation is different. The ISPs are under no obligation to break and inspect encrypted traffic. Owners and operators of home and corporate networks have an entirely different(and justifiable) set of concerns.

Re: Encrypted Client Hello

#138

Post by LinuxBender »

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…

That DNS module for IPTables actually looks to be a bit outdated and is missing the type HTTPS as far as I can tell so maybe a request to the people at nlnetlabs to add options for query types to block in Unbound DNS may be useful.

Re: Encrypted Client Hello

#139

Post by catiopatio »

ocdtrekkie wrote: post #135
catiopatio wrote: post #130

Earlier quoted context omitted.

> SNI monitoring is a reasonable compromise, and I think a healthy one No, it’s not. ISPs have no right to know who I am speaking to or why.

I mean you have no right to use their networks either. You generally agree to terms as a condition of use of said networks.

I didn’t agree to terms that require I provide them with plaintext traffic to analyze.

Re: Encrypted Client Hello

#140

Post by briHass »

josephcsible wrote: post #91
hkt wrote: post #59

Earlier quoted context omitted.

As jeremiads go, this is golden. I for one and persuaded and am grateful you wrote it. I hadn't considered before that DoH effectively takes an avenue away from people who want to block advertising and trackers. This makes it a fiercely unpleasant thing working against users. Personally, I'm switching to DNS over TLS instead.

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.

Post reply on HN