undefined

points

[-]

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

by boondongle12 hours ago|

prev|

[-]

The tension is that Security and Dev parts of the stack remove the actual troubleshooting capabilities of the Network layer without opening up the tools that are supposed to replace them.

It's not a problem if Network can still do their job. It's a whole other matter to expect Network to do their job through another layer. You end up with organizations that can't maintain their applications and expect magic fixes.

Orgs that are cooperative probably don't have this issue but there are definitely parts of some organizations that when one part takes capability from another they don't give it back in some sort of weird headcount game despite not really wanting to understand Network to a Network level.

by Hizonner1 hours ago|

parent|

[-]

The network's job is to move packets from A to B, based on the addresses in the headers. Full stop.

by deep128311 hours ago|

parent|

prev|

[-]

This feels like a recurring pattern in the stack. abstraction removes visibility faster than tooling replaces it.

Encryption and higher-level platforms are great for security and productivity, but the debugging surface keeps shrinking. Eventually when something breaks, nobody actually has the layer-by-layer visibility needed to reason about it.

by hypeatei8 hours ago|

prev|

[-]

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

by tialaramex7 hours ago|

parent|

[-]

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.

by hypeatei6 hours ago|

parent|

[-]

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.