Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 9849. TLS Encrypted Client Hello

rfc-editor.org

Post reply on HN
Print view View original

91–100 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#91

Post by EvanAnderson »

AgentK20 wrote: post #84
ndriscoll wrote: post #81

Earlier quoted context omitted.

> A pretty interesting feature of ECH is that the server does not need to validate the public name (it MAY) , so clients can use public_name's that middleboxes (read: censors) approve to connect to other websites. I'm trying to get this added to the RustTLS client[1], now might be a good time to pick that back up. Note that it is exactly this type of thing that makes age verification laws reasonable. You're making it…

How does ECH make it impossible for parents to control their children's access to computers? Sure they can't block sites at the router level, just like your ISP won't be able to block things at the ISP level, but you (the parent) have physical access to the devices in question, and can install client-side software to filter access to the internet. The only thing this makes impossible is the laziest, and easiest to by…

Because there are network operators who have mal-intent increasingly no network operators are permitted to exercise network-level control. A parent who wants to filter the network access in their house is the same as a despotic regime practicing surveillance and censorship on their citizens.

Given that it's pretty much the norm that consumer embedded devices don't respect the owner's wishes network level filtering is the best thing a device owner can do on their own network.

It's a mess.

I'd like to see consumer regulation to force manufacturers to allow owners complete control over their devices. Then we could have client side filtering on the devices we own.

I can't imagine that will happen. I suspect what we'll see, instead, is regulation that further removes owner control of their devices in favor of baking ideas like age or identity verification directly into embedded devices.

Then they'll come for the unrestricted general purpose computers.

Re: RFC 9849. TLS Encrypted Client Hello

#92

Post by Bjartr »

ndriscoll wrote: post #86
AgentK20 wrote: post #84

Earlier quoted context omitted.

How does ECH make it impossible for parents to control their children's access to computers? Sure they can't block sites at the router level, just like your ISP won't be able to block things at the ISP level, but you (the parent) have physical access to the devices in question, and can install client-side software to filter access to the internet. The only thing this makes impossible is the laziest, and easiest to by…

"Sure, you can use my wifi while you're over. Just enroll in MDM real quick". As brought up in another thread on the topic, you have things like web browsers embedded in the Spotify app that will happily ignore your policy if you're not doing external filtering.

There's nothing technical stopping device manufacturers from making this easy for parents to do. They choose not to.

Re: RFC 9849. TLS Encrypted Client Hello

#93

Post by mholt »

arowthway wrote: post #77
francislavoie wrote: post #21

(Disclosure: I'm a Caddy maintainer), Caddy already supports ECH, leaning on the DNS plugins to automate setting the DNS HTTPS records to wire it up. Here's a lot of technical detail about it https://caddyserver.com/docs/automatic-https#encrypted-clien...

Nginx also supports ECH now, since the December release.

But does it automatically provision the DNS records and rotate the keys?

I'm actually kind of furious at nginx's marketing materials around ECH. They compare with other servers but completely ignore Caddy, saying that they're the only practical path to deploying ECH right now. Total lies: https://x.com/mholt6/status/2029219467482603717

Re: RFC 9849. TLS Encrypted Client Hello

#94

Post by hypeatei »

deep1283 wrote: post #60

ECH is great from a privacy perspective, but I’m curious how well this will actually work in practice.every time the web encrypts more metadata there’s pushback from middleboxes and network operators.

ECH won't be effective until there's a HSTS-style policy that forces browsers to use it. Otherwise, firewalls will continue to strip parameters and downgrade connections[0].

0: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Ho...

Re: RFC 9849. TLS Encrypted Client Hello

#95

Post by ndriscoll »

kstrauser wrote: post #89
ndriscoll wrote: post #81

Earlier quoted context omitted.

> A pretty interesting feature of ECH is that the server does not need to validate the public name (it MAY) , so clients can use public_name's that middleboxes (read: censors) approve to connect to other websites. I'm trying to get this added to the RustTLS client[1], now might be a good time to pick that back up. Note that it is exactly this type of thing that makes age verification laws reasonable. You're making it…

My right to access free information, and my global neighbor’s right to read unofficial information without being jailed or killed for it, outweighs your right to let your right use the Internet without supervision.

Sure, and if we want to prioritize your ability to do so despite living in an authoritarian hellhole, those of us in countries that respect their citizens rights will have to put these verification systems in place. It just needs to be understood by technologists building this stuff that this is the tradeoff they're making.

And it's likely a temporary win there until the authoritarian regimes mandate local monitoring software and send you to the gulag if they detect opaque traffic.

Re: RFC 9849. TLS Encrypted Client Hello

#96

Post by RandyOrion »

TLS Encrypted Client Hello (ECH) standard is another attempt on encrypting plaintext Server Name Indication (SNI). It is very useful for circumventing SNI-based censorship, which is adopted for years by state-backed systems like the Great Firewall (GFW).

The previous attempt of encrypting plaintext SNI is Encrypted Server Name Indication (ESNI), which didn't end well.

Re: RFC 9849. TLS Encrypted Client Hello

#98

Post by sgjohnson »

boondongle wrote: post #75
arch-choot wrote: post #39

Earlier quoted context omitted.

If i'm not mistaken its because IPs are actually much easier to rotate than domains. E.g. all the users will remember `example.com` , underlying it doesn't matter what IP it resolves to. If the IP gets "burned" , then the providers can rotate to a new IP (if their provider allows). Vs. telling your users to use a new domain `example.org` , fake websites etc. Also sensible ISPs usually don't block IPs since for servic…

I wouldn't say you're mistaken, but it's a simplification. In the network world, the capability exists to restrict what BGP advertisements are accepted via RPKI/a peer. Internet providers usually don't because the premium is placed on uptime/connectivity. If tomorrow, everyone said "we don't want IP's from Frankfurt showing up somewhere in Dubai", you'd have a massive technical problem and rearranging to start with b…

> we don't want IP's from Frankfurt showing up somewhere in Dubai

what do you mean, IPs from Frankfurt?

IP addresses are just IP addresses, they know no geographical boundaries. In RIR DBs you can geolocate them to wherever you want. Which is the entire reason why Geo IP DBs even exist - they triangulate.

Re: RFC 9849. TLS Encrypted Client Hello

#99

Post by JoshTriplett »

EvanAnderson wrote: post #91
AgentK20 wrote: post #84

Earlier quoted context omitted.

How does ECH make it impossible for parents to control their children's access to computers? Sure they can't block sites at the router level, just like your ISP won't be able to block things at the ISP level, but you (the parent) have physical access to the devices in question, and can install client-side software to filter access to the internet. The only thing this makes impossible is the laziest, and easiest to by…

Because there are network operators who have mal-intent increasingly no network operators are permitted to exercise network-level control. A parent who wants to filter the network access in their house is the same as a despotic regime practicing surveillance and censorship on their citizens. Given that it's pretty much the norm that consumer embedded devices don't respect the owner's wishes network level filtering is…

If you have a device you don't trust, don't allow it on your network, or have an isolated network for such devices. Meanwhile, devices are right to not allow MITMing their traffic and to treat that as a security hole, even if a very tiny fraction of their users might want to MITM it to try to do adblocking on a device they don't trust or fully control, rather than to exploit the device and turn it into a botnet.

Along similar lines, a security hole you can use for jailbreaking is also a security hole that could potentially be exploited by malware. As cute as things like "visit this webpage and it'll jailbreak your iPhone" were, it's good that that doesn't work anymore, because that is also a malware vector.

I'd like to see more devices being sold that give the user control, like the newly announced GrapheneOS phones for instance. I look forward to seeing how those are received.

Re: RFC 9849. TLS Encrypted Client Hello

#100

Post by bnjms »

ndriscoll wrote: post #81
arch-choot wrote: post #12

Glad that it's published, I'd been following it since ESNI draft days. Was pretty useful back when I was in India since Jio randomly blocked websites, and cloudflare adopted the ESNI draft on its servers as did Firefox client side which made their SNI based blocking easy to bypass. There was a period where I think both disabled ESNI support as work was made on ECH, which now is pretty far along. I was even able to se…

> A pretty interesting feature of ECH is that the server does not need to validate the public name (it MAY) , so clients can use public_name's that middleboxes (read: censors) approve to connect to other websites. I'm trying to get this added to the RustTLS client[1], now might be a good time to pick that back up. Note that it is exactly this type of thing that makes age verification laws reasonable. You're making it…

This is exactly reverse of the right idea. If parents need to censor things the solutions are the same as corpos are going to. Put the censors at the device or “mitm” the connection, either actually with a proxy, or maybe with a browser and curated apps - which is again on the device.
Post reply on HN