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

141–150 of 219 posts

Re: Encrypted Client Hello

#141

Post by KirillPanov »

josephcsible wrote: post #101
dilyevsky wrote: post #37

Earlier quoted context omitted.

You could just as easily make df opt-in. Another way is to use “fake” cloudflare-df.com sni just like they are doing with cloudflare-ech.com outer sni

A designated domain for domain fronting is useless because it would immediately get added to every middlebox's list of blocked domains.

... and this is exactly what will happen to cloudflare-ech.com.

I'm really disappointed with how the ECH spec panned out. It's almost like "make sure middleboxes and GFW can block this" was a hard requirement. They should've made the handshake look like a session resumption (i.e. pre-shared key), since those aren't required to send a server name.

Re: Encrypted Client Hello

#142

Post by Groxx »

ignoramous wrote: post #124
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…

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

I think the remark is because: MITM would allow them to spoof the DNS response entirely, so they can replace it with whatever key they want. Doesn't matter what level of security the key claims at that point, it's attacker-controlled and they can just read whatever you send next.

Re: Encrypted Client Hello

#143

Post by KirillPanov »

elashri wrote: post #114

It is surprising that if you are on the free plan then “Enabled by default for Free zones.”

Actually it's kinda smart.

cloudflare-ech.com is going to be blocked by the Great Firewall and every other state-level filtering apparratus approximately ten nanoseconds from whenever this blog was posted.

Cloudflare needs a bunch of not-objectionable-to-governments sites in the anonymity set. For these sites, being in the anonymity set has a cost (a few of your visitors can't get to your website) but zero benefit.

For the free plan customers, Cloudflare kinda doesn't care about slightly pissing them off. They aren't paying anything. As long as they aren't all so pissed off that all of them leave simultaneously, Cloudflare is free to take advantage of them for both benevolent (as here) and nefarious (other situations) purposes.

Re: Encrypted Client Hello

#144

Post by yardstick »

> The outer SNI is a common name that, in our case, represents that a user is trying to visit an encrypted website on Cloudflare. We chose cloudflare-ech.com as the SNI that all websites will share on Cloudflare. Because Cloudflare controls that domain we have the appropriate certificates to be able to negotiate a TLS handshake for that server name.

All this really means is operators that inspect SNI will now just block cloudflare-ech.com.

It’s a tug-o-war between cloud flare and the ISPs and network admins, essentially.

Re: Encrypted Client Hello

#145

Post by d-z-m »

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…

> 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 out, people are going to notice.

Re: Encrypted Client Hello

#146

Post by Obscurity4340 »

missingrib wrote: post #134
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…

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…

Is it a fair conjecture that in some sense there's an issue with cryptographer's trying to push the field in terms of the efficacy and robustness of encryption forward while "the government"s continually work all manner of trickery to hamper these efforts in subtle and not-so-subtle but gag-ordered-enforced ways?

I feel like there's this constant ridiculous pushback on any digital product or protocol or service being air-tight cryptographically and implementationally speaking when they can basically already build air-tight cases via parallel construction with the help of the infinite resources available upon (often not even) receipt of a warrant?

Its very strange. The obsession is always on completely neutering/compromising the technology and never on actually doing the damn police work they are enpowered to approach laterally like they did before typewriters and telephones/wire-taps or bending the providions of constitutions they swore to protect and enforce until its a simulacrum of its original concept.

Like, it always comes across as they feel that their entire case is lost if they can only prove something 5 different ways instead of 6. It wouldn't be so problematic if humans weren't so human and law enforcement wasn't emphatically staffed by humans who are liable to abuse things to maximize their money, power, and prestige and have the absolute or qualified immunity to get away with it at least once regardless of how it damages the targets of their misconduct.

Re: Encrypted Client Hello

#147

Post by d-z-m »

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…

Sounds kind of similar to [0].

TL;DR: stealth secondary DH key exchange in the nonce field of Client/Server Hello in TLS 1.3.

[0]: https://eprint.iacr.org/2023/651.pdf

Re: Encrypted Client Hello

#148

Post by Obscurity4340 »

infinityio wrote: post #133
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…

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

Weren't some of these widespread conventions in some sense strategically designed or implemented in such a way as to ensure backdoors and/or contrived vulnerabillities? Something, something purposefully smaller key sizes or special "weaker" variables than was practicable or other trickery that always ostensibly has an economic or other seemingly justifiable underpinning but introduces unacceptable security compromises that arise later and predictably.

Re: Encrypted Client Hello

#149

Post by doublepg23 »

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?

I mean yeah, if you don't trust the devices on your network...don't add them to your network?

Re: Encrypted Client Hello

#150

Post by gizmo686 »

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…

The general purpose quantum magic is Grover's algorith https://en.m.wikipedia.org/wiki/Grover%27s_algorithm.

Grover's algorithm is a general solution to the search problem. Given an arbitrary (computable) function f: X -> Y, and a desired value y in the codomain, find a value x such f(x) = y. For the sake of simplicity, assume that x is unique (although a Grover's algorithm can be extenef to not have this constraint).

Let N be the size of the domain X. On a classical computer, without any additional information, the optimal solution is to simply iterate through X trying inputs until you find the correct one. On average you will need to evaluate f on half the possible inputs, which is N/2. In the worst case, you need to try all N.

Using Grover's algorithm, you can solve the problem with only sqrt(N) invocations of f, which is a quadratic speed up compared with classical computers.

Applying this to encryption keys: for a keylenth of n, we have 2^n possible keys. Classically speaking, you would need to try decrypting (2^n)/2 = 2^(n-1) times. But with Grover's algorithm, you can find the correct key after decrypting judt sqrt(2^n) = 2^(n/2) times, which is the classical worst case for a key of half the length. Note that this is still exponential in the size of the key, so is not a fundamental game changer.

This has nothing to do with prime factoring or the discrete log problem. Those have even better quantum algorithms (Shor's) that can solve them in polynomial time, which would be a major game changer if they ever become practical.

Post reply on HN