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

121–130 of 219 posts

Re: Encrypted Client Hello

#121

Post by dilyevsky »

andrewaylett wrote: post #75
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 o…

This explanation makes sense, thanks! I mean other than the fact you’re still trusting cloudflare not to mess with the data since it’s terminating ssl =) but i agree that makes this somewhat cleaner from client perspective

Re: Encrypted Client Hello

#122

Post by dilyevsky »

fivre wrote: post #69
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…

Afaik fastly still has fronting working and it’s how tor snowflake node info is distributed while pretending to be azure or something

Re: Encrypted Client Hello

#123

Post by madeofpalk »

ocdtrekkie wrote: post #109
josephcsible wrote: post #105

Earlier quoted context omitted.

> I expect any sane network to do the same. Why? Sane networks shouldn't block anything. Even super dangerous stuff like ports 135-139 and 445 are a morally gray area. > The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors. How is privacy unhinged? Isn't that basically the same as the argument that we need to gut the Fourth Amendment because of terrorists and…

[flagged]

What is a "privacy focused app"?

Is Chrome, which aggressively supports and promotes HTTP a "privacy focused app"?

Re: Encrypted Client Hello

#124

Post by ignoramous »

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 traffic analysis is thwarted. ECH plugs inspection of the only plaintext bits in TLS, which is not only abused by censors, but also by various 'well-meaning' middleware that made bringing upgrades to TLSv1.3 a nightmare.

> If we take away this last resort from governments...

You mention GFW, and we got GFW without ECH. Governments will government, nothing will stop them. That shouldn't stop us from shoring up our side of the equation. Because by that logic, Meta shouldn't e2ee WhatsApp or Browsers shouldn't OCSP / CRL. In fact, not having those sound scary to me; because governments aren't the only power hungry actor around. It wasn't long ago Meta was caught spying on the users of its data saver VPN (Onavo) for half a decade, if not more.

Re: Encrypted Client Hello

#125

Post by Obscurity4340 »

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…

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

It seems with QC, there's this collective magical thinking that they offer this magical free lunch that is inaccessable via more traditional means. I don't get what the seemingly non-existent tradeoffs or optimizations that are being made to achieve this...

Re: Encrypted Client Hello

#126

Post by madeofpalk »

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

Here, Cloudflare is "the website" because they're terminating the TLS.

Re: Encrypted Client Hello

#127

Post by jmprspret »

josephcsible wrote: post #105
ocdtrekkie wrote: post #100

Earlier quoted context omitted.

We will almost certainly block ECH at my work, as we already block DoH. I expect any sane network to do the same. The natural alternative if blocking these protocols becomes unsustainable will absolutely be to require full decryption at our security edge. And that will provide drastically more information to us than we have now and will absolutely feel invasive. The idea of uninspectable client traffic is somewhat un…

> I expect any sane network to do the same. Why? Sane networks shouldn't block anything. Even super dangerous stuff like ports 135-139 and 445 are a morally gray area. > The idea of uninspectable client traffic is somewhat unhinged, and is already heavily used by malicious actors. How is privacy unhinged? Isn't that basically the same as the argument that we need to gut the Fourth Amendment because of terrorists and…

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

Re: Encrypted Client Hello

#128

Post by [deleted] »

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.

[deleted]

Re: Encrypted Client Hello

#129

Post by mehlmao »

josephcsible wrote: post #93
nfoz wrote: post #70

Earlier quoted context omitted.

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.

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?

Re: Encrypted Client Hello

#130

Post by catiopatio »

ocdtrekkie wrote: post #118
josephcsible wrote: post #117

Earlier quoted context omitted.

By that logic, wouldn't every ISP have a moral obligation to MITM all of their customers' traffic? Obviously that's wrong.

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.

Post reply on HN