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

111–120 of 159 posts

Re: RFC 9849. TLS Encrypted Client Hello

#111

Post by icehawk »

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"

From a network perspective statements like that make no sense. IP addresses don't have any sort of physicality,

Re: RFC 9849. TLS Encrypted Client Hello

#112

Post by hypeatei »

tialaramex wrote: post #106
hypeatei wrote: post #94

Earlier quoted context omitted.

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

Well, yes, this is being used in corporate environments but the end user and the system admin aren't on the same page necessarily. Domain blocking doesn't make much sense in my opinion and should be a thing of the past. You already lack admin rights so what is a block on e.g. mullvad.net actually doing other than stopping someone from reading their blog? They can't install the VPN software.

Defense in layers makes sense, but domain blocking was never a "layer" if a hostile actor can just buy a new domain that's not on your blocklist.

I think it'd be good if ECH became more widespread so that we can get away from these antiquated control techniques that just result in frustration with no security benefits.

Re: RFC 9849. TLS Encrypted Client Hello

#113

Post by iamnothere »

ndriscoll wrote: post #90
AgentK20 wrote: post #88

Earlier quoted context omitted.

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

Yes well some of us live in first world countries that are at risk of declining into third world status, where some states DO actually care what sites you visit and would jump at the chance to further restrict traffic.

Rather than “get over” it I think we need to fight. You seem to insist that monitoring/control is a done deal and we only need to argue about the form it takes, but this is not correct. Centralized monitoring/control can be resisted and broken through a combination of political and technical means. While you may not want this, I do. (And many others are being swayed back in my direction as they start to feel the effects of service enshittification, censorship under the guise of “fighting misinformation”, and media consolidation.)

Re: RFC 9849. TLS Encrypted Client Hello

#114

Post by kstrauser »

ndriscoll wrote: post #95
kstrauser wrote: post #89

Earlier quoted context omitted.

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…

Ironically, or perhaps not, I think we’re both posting from the US. I am.

Re: RFC 9849. TLS Encrypted Client Hello

#115

Post by pocksuppet »

icehawk wrote: post #111
boondongle wrote: post #75

Earlier quoted context omitted.

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" From a network perspective statements like that make no sense. IP addresses don't have any sort of physicality,

They have registration data. Someone could declare they don't want IPs registered to companies from Frankfurt with geofeeds in Frankfurt to be advertised in Dubai.

Re: RFC 9849. TLS Encrypted Client Hello

#116

Post by pocksuppet »

ndriscoll wrote: post #105
bnjms wrote: post #100

Earlier quoted context omitted.

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.

Why would you want to censor based on network? You don't want to censor based on network, you want to censor based on device. If your 8yo kid is blocked from pornhub, that doesn't mean everyone on your network is blocked from pornhub, and you having the ability to even know if someone on your network is browsing pornhub is a security risk.

Re: RFC 9849. TLS Encrypted Client Hello

#117

Post by 0x457 »

jeroenhd wrote: post #26
lxgr wrote: post #22

Earlier quoted context omitted.

The colon isn’t a valid character in DNS, so there’s just no risk of confusing IPv6 addresses (which contain at least one colon in all notations I’ve seen). For IPv4, there’s room for ambiguity. And how are IP certificates required for small servers?

> For IPv4, there’s room for ambiguity. I can't think of a single numeric TLD, so I don't think anyone is confusing IP literals with domain names, unless they're doing so extremely lazily. > And how are IP certificates required for small servers? You need a valid certificate as the outer certificate which contains an SNI that will still be readable. For cloudflare.com and google.com that's easy; you can't tell what w…

Probably why TLD requires the first character to be an alpha character. com3 is okay, but 3com is not. Unless it's to protect spec against ignoring that requirement I don't see where confusing could surface.

Re: RFC 9849. TLS Encrypted Client Hello

#118

Post by shae »

arowthway wrote: post #78
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…

The server can also advertise a public name that doesn't match any domain it has a TLS certificate for, like example.com or nsa.gov. I'm not 100% sure it's allowed in the specs, but it works in Chrome. As I understand it, without this feature it would be pretty useless for small website owners, since they would need to register a separate domain for their ECH public name, which censors could just block.

I saw this used to obfuscate spam yesterday! Yay?

Re: RFC 9849. TLS Encrypted Client Hello

#119

Post by hnav »

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…

A lot of endpoint protection products rely on SNI sniffing. E.g. Apple's network extensions filters look at TLS handshakes.
Post reply on HN