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

81–90 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#81

Post by ndriscoll »

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 technically impossible for even sophisticated parents to censor things without a non-solution like "don't let kids use a computer until they're 18", so naturally the remaining solution is a legal one to put liability on service operators.

You're still ultimately going to get the censorship when the law catches up in whatever jurisdiction, but you'll also provide opacity for malware (e.g. ad and tracking software) to do its thing.

Re: RFC 9849. TLS Encrypted Client Hello

#83

Post by josefx »

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…

> "don't let kids use a computer until they're 18"

Ideally you would lock them up in a padded room until then. There is a significant amount of shared real world space that isn't supervised and doesn't require any age verification to enter either.

Re: RFC 9849. TLS Encrypted Client Hello

#84

Post by AgentK20 »

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…

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 bypass method of filtering the internet.

Re: RFC 9849. TLS Encrypted Client Hello

#85

Post by ndriscoll »

josefx wrote: post #83
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…

> "don't let kids use a computer until they're 18" Ideally you would lock them up in a padded room until then. There is a significant amount of shared real world space that isn't supervised and doesn't require any age verification to enter either.

Notably, explicitly adult spaces like bars and porn shops are not among them, and a significant amount of virtual space would also not require age verification for the same reason.

Re: RFC 9849. TLS Encrypted Client Hello

#86

Post by ndriscoll »

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…

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

Re: RFC 9849. TLS Encrypted Client Hello

#87

Post by darig »

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…

[dead]

Re: RFC 9849. TLS Encrypted Client Hello

#88

Post by AgentK20 »

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.

Fair point.

I guess it (network-level filtering) just feels like a dragnet solution that reduces privacy and security for the population at large, when a more targeted and cohesive solution like client-side filtering, having all apps that use web browsers funnel into an OS-level check, etc would accomplish the same goals with improved security.

Re: RFC 9849. TLS Encrypted Client Hello

#89

Post by kstrauser »

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…

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.

Re: RFC 9849. TLS Encrypted Client Hello

#90

Post by ndriscoll »

AgentK20 wrote: post #88
ndriscoll wrote: post #86

Earlier quoted context omitted.

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

Fair point. I guess it (network-level filtering) just feels like a dragnet solution that reduces privacy and security for the population at large, when a more targeted and cohesive solution like client-side filtering, having all apps that use web browsers funnel into an OS-level check, etc would accomplish the same goals with improved security.

I think the population at large generally needs to get over their hangups (actually, maybe they have, and it's just techies). No one in a first world country cares if you visit pornhub just like no one cares if you go to amazon. Your ISP has had the ability to see this since the beginning of the web. It does not matter, but we can also have privacy laws restricting their (and everyone else like application/service vendors) ability to record and share that information. If you really want, you can hide it with a VPN or Tor. As long as not everything is opaque, it's easy to block that traffic if you'd like (so e.g. kids can't use it). In a first world country, this works fine since actually no one cares if you're hiding something, so you don't need to blend in. At a societal level, opaque traffic is allowed.

You could have cooperation from everyone to hook into some system (California's solution), which I expect will be a cover for more "we need to block unverified software", or you could allow basic centralized filtering as we've had, and ideally compel commercial OS vendors to make it easy to root and MitM their devices for more effective security.

Post reply on HN