| ▲ | ocdtrekkie 5 hours ago |
| Just be aware any reasonable network will block this. |
|
| ▲ | Bender 4 hours ago | parent | next [-] |
| Just be aware any reasonable network will block this. Russia blocked it for Cloudflare because the outer SNI was obviously just for ECH but that won't stop anyone from using generic or throw-away domains as the outer SNI. As for reasonable I don't quite follow. Only censorious countries or ISP's would do such a thing. I can foresee Firewall vendors possibly adding a category for known outer-SNI domains used for ECH but at some point that list would be quite cumbersome and may run into the same problems as blocking CDN IP addresses. |
|
| ▲ | kstrauser 3 hours ago | parent | prev | next [-] |
| Once upon a time, "reasonable networks" blocked ICMP, too. They were wrong then, of course, and they're still wrong now. |
| |
| ▲ | ocdtrekkie 3 hours ago | parent [-] | | Once upon a time, like today? ICMP is most definitely only allowed situationally through firewalls today. | | |
| ▲ | tredre3 3 hours ago | parent | next [-] | | I'd say that ICMP is only situationally blocked by firewalls, not the other way around. Because I can ping almost any public server on the internet and they will reply. I can ping your website just fine and it replies to me! | | |
| ▲ | ocdtrekkie 40 minutes ago | parent [-] | | You'd say incorrectly, firewalls have an implicit deny rule, so any case ICMP traverses a firewall, someone wanted it to. Obviously large hosting providers tend to find value in ICMP being enabled. But for example, our firewall at work responds to ICMP but all of the endpoints which aren't meant for public use do not. That is less because ICMP is a problem and more because everything works fine without it and least privilege is good design. ICMP is also more than just ping, and some parts of ICMP are considered a vulnerability if exposed to the public internet by some scanning services. |
| |
| ▲ | kstrauser 2 hours ago | parent | prev [-] | | That kind of cargo culted tradition is how you end up with weird packet loss and VPNs that flat-out refuse to work. I could be convinced to block inbound pings. Anything past that and I'd want solid evidence that it wouldn't break anything, with the expectation that it would. |
|
|
|
| ▲ | quantummagic 5 hours ago | parent | prev | next [-] |
| Why is it "reasonable" to block it? |
| |
| ▲ | vman81 5 hours ago | parent [-] | | Well, I may want to have a say in what websites the employees at work access in their browsers. For example. | | |
| ▲ | altairprime 4 hours ago | parent | next [-] | | That’s not a meaningful issue here. Either snoop competently or snoop wire traffic, pick one. In the snooping-mandatory scenario, either you have a mandatory outbound PAC with SSL-terminating proxy that either refuses CONNECT traffic or only allows that which it can root CA mitm, or you have a self-signed root CA mitm’ing all encrypted connections it recognizes. The former will continue functioning just fine with no issues at providing that; the latter will likely already be having issues with certificate-pinned apps and operating system components, not to mention likely being completely unaware of 80/udp, and should be scheduled for replacement by a solution that’s actually effective during your next capital budgeting interval. | |
| ▲ | kccqzy 4 hours ago | parent | prev [-] | | That’s usually done not on the network side but through the device itself. Think MDM and endpoint management. | | |
| ▲ | ocdtrekkie 4 hours ago | parent [-] | | A good solution is tackling it on both. At work we have network level firewalls with separate policies for internal and guest networks, and our managed PCs sync a filter policy as well (through primarily for when those devices are not on our network). The network level is more efficient, easier to manage and troubleshoot, and works on appliances, rogue hardware, and other things that happen not to have client management. | | |
|
|
|
|
| ▲ | hypeatei 5 hours ago | parent | prev [-] |
| Procrastinators. FTFY. Eventually these blocks won't be viable when big sites only support ECH. It's a stopgap solution that's delaying the inevitable death of SNI filtering. |
| |
| ▲ | ocdtrekkie 4 hours ago | parent [-] | | This will never happen. Because between enterprise networks and countries with laws, ECH will end up blocked a lot of places. Big sites care about money more than your privacy, and forcing ECH is bad business. And sure, kill SNI filtering, most places that block ECH will be happy to require DPI instead, while you're busy shooting yourself in the foot. I don't want to see all of the data you transmit to every web provider over my networks, but if you remove SNI, I really don't have another option. | | |
| ▲ | hypeatei 3 hours ago | parent [-] | | > Because between enterprise networks > require DPI Enterprises own the device that I'm connected to the network with, I don't see how you can get any more invasive than that. > countries with laws 1) what countries do national-level SNI filtering, and 2) why are you using a hyptothetical authoritarian, privacy invading state actor as a good reason to keep plaintext SNI? > Big sites care about money Yes, and you could say that overbearing, antiquated network operators stop them from making more money with things like SNI filtering. |
|
|