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

101–110 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#101

Post by ndriscoll »

JoshTriplett wrote: post #99
EvanAnderson wrote: post #91

Earlier quoted context omitted.

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

Network segmentation does nothing for the types of attacks these devices perform (e.g. content recognition for upload to their tracking servers, tracking how you navigate their UI, ad delivery). I'm not worried about them spreading worms on my network. The problem is their propensity to exfiltrate data or relay propaganda. The solution to that is a legal one, or barring that, traffic filtering.

Re: RFC 9849. TLS Encrypted Client Hello

#102

Post by tialaramex »

ndriscoll wrote: post #85
josefx wrote: post #83

Earlier quoted context omitted.

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

Rules vary. In Britain it was completely normal for say 15-year old me to be in a bar - it was illegal to buy booze but not a problem to be there. But when I travelled to Austin aged 19 I couldn't meet adult members of my team in the hotel bar because I wasn't old enough even though by then I was legal to drink, to marry, to go to war and so on in my own country.

A little while after that, back in the UK, I drove my young cousin to the seaside. I didn't carry ID - I don't drink and you're not required to carry ID to drive here† so it was never necessary back then, but she did, so I try to buy her booze, they demand ID, I do not have any ID so I can't buy it even though I'm old enough to drink. So, she just orders her own booze, she's under age but they don't ask because she's pretty.

† The law here says police are allowed to ask to see a driving license if you're in charge of a vehicle on a public road, but, since you aren't required to carry it they can require you to attend a police station and show documents within a few days. In practice in 2026 police have network access and so they can very easily go from "Jim Smith, NW1A 4DQ" to a photo and confirmation that you're licensed to drive a bus or whatever if you are co-operative.

Re: RFC 9849. TLS Encrypted Client Hello

#103

Post by JoshTriplett »

ndriscoll wrote: post #101
JoshTriplett wrote: post #99

Earlier quoted context omitted.

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

Network segmentation does nothing for the types of attacks these devices perform (e.g. content recognition for upload to their tracking servers, tracking how you navigate their UI, ad delivery). I'm not worried about them spreading worms on my network. The problem is their propensity to exfiltrate data or relay propaganda. The solution to that is a legal one, or barring that, traffic filtering.

That was my motivation for the "or" (don't allow it on your network, or put it on an isolated network); it depends on your threat model and what the device could do. Some devices (like "smart" TVs) shouldn't have network access at all.

Re: RFC 9849. TLS Encrypted Client Hello

#104

Post by MBCook »

RandyOrion wrote: post #96

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.

As someone hasn’t followed this, what was wrong with ESNI?

Re: RFC 9849. TLS Encrypted Client Hello

#105

Post by ndriscoll »

bnjms wrote: post #100
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…

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.

This brings us back to "sure you can use my guest wifi, just install my root CA/enroll in MDM".

I do agree though that it should be illegal for device manufacturers or application developers to use encryption that the device owner cannot MitM. The owner should always be able to install their own CA and all applications should be required to respect it.

Re: RFC 9849. TLS Encrypted Client Hello

#106

Post by tialaramex »

hypeatei wrote: post #94
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...

The Fortigate article proposes that you take a profile in which your end users have said OK, I trust the Fortigate to decide what's allowed, and then you set it to not allow them to use ECH.

Notice that if users don't trust the Fortigate all it can do is IP layer blocks, exactly as intended.

It seems pointless to try to have a policy where people say they trust somebody else (whoever is operating that Fortigate) to override their will but also they don't want their will overridden, that's an incoherent policy, there's no technical problem there, technology can't help.

Re: RFC 9849. TLS Encrypted Client Hello

#107

Post by elric »

Every time some security related protocol relies on DNS for its magic (looking at you, ACME), I lament the state of DNS providers. They all have different APIs, with different levels of security. Most at least offer some kind of REST API with API tokens for auth, which is relatively easy to set up.

Many of those (not looking at any particular Germans..) however only offer a single API token across all DNS zones, which is awful when you're managing many zones. One compromised API token = hundreds of compromised zones.

Would be nice if more DNS providers offered granular API tokens, at least on a per-zone basis and ideally on a per-record basis within a zone.

Re: RFC 9849. TLS Encrypted Client Hello

#108

Post by tialaramex »

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.

> I’m curious how well this will actually work in practice

You're experiencing it working in practice. RFC9849 is a published document, the end of a very long process in which the people who make this "actually work in practice" decided how to do this years ago and have deployed it.

This isn't like treaty negotiation where the formal document often creates a new reality, the RFC publication is more like the way the typical modern marriage ceremony is just formalising an existing reality. Like yeah, yesterday Bill and Sarah were legally not married, and today Bill and Sarah are married, but "Bill and Sarah" were a thing five Christmases ago, one of the bridesmaids is their daughter, we're just doing some paperwork and having a party.

Re: RFC 9849. TLS Encrypted Client Hello

#110

Post by tptacek »

jeroenhd wrote: post #20
micw wrote: post #8

Earlier quoted context omitted.

If the load balancer can force a downgrade, an attacker can do it as well.

Only if the attacker has a valid certificate for the domain to complete the handshake with. Relying on HTTPS and SVCB records will probably allow a downgrade for some attackers, but if browsers roll out something akin to the HSTS preload list, then downgrade attacks become pretty difficult. DNSSEC can also protect against malicious SVCB/HTTPS records and the spec recommends DoT/DoH against local MitM attacks to preve…

DNSSEC can't protect against an ECH downgrade. ECH attackers are all on-path, and selectively blocking lookups is damaging even if you can't forge them. DoH is the answer here, not record integrity.
Post reply on HN