Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare)
I wanted to link CF efforts on this also but somehow I forgot. Thanks for sharing and I really hope you are successful at this because what I experienced yesterday was really infuriating. Even if having everything behind a CDN to avoid ISP spying is still not the optimal solution, but at least is an improvement given what ISPs have already shown.
Part of the counter-argument that has been so prevalent on HN (most recently: [0]) is that when you prevent middlemen on your network from being able to see what website you're browsing, you're doing exactly that: preventing anyone, even a trusted network administrator, from being able to inspect traffic. I'm all for DoH and ECH since US ISPs have a history of inspecting and logging traffic, but it seems like there should be a way to manage the devices on your network besides being forced to set up MDM on everything.
Managing traffic over your network and the devices on your network are very similar tasks that aim to accomplish very similar things. However, they are not equivalent tasks. Relying on traffic management to accomplish device management eventually runs into conflicts. These may stem from unmanaged devices, guest devices, unmanageable devices, or the consequences of the total lack of authentication and authorization.
Ultimately, managing traffic and managing devices are not tasks that replace one another.
> it seems like there should be a way to manage the devices on your network
Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.
My ways of dealing with the modern world, in order of preference:
1. Use Free software, so that devices develop user-empowering features instead of being locked down.
2. Firewall all general Internet access from a device/VM, and let it talk to local network devices only.
3. Firewall the device/VM from accessing most of your network, allow Internet access (ideally through a VPN), and inspect the hardware to make sure there aren't microphones or cameras.
The vast majority of users do not have a "trusted network administrator"; they have a hostile upstream network. That's where the defaults come from. Trusting the network (or anything outside of the device itself) should always be a non-default setting, and nothing from the network should be able to change that setting. You should have the option of configuring a device you own and control to make its traffic inspectable, but that should never be the default.
> a way to manage the devices on your network besides being forced to set up MDM on everything.
It's sort of like cleaning malware off of an infected PC from within the infected OS.
It was always theoretically impossible, and now we're just seeing the gap of "Well in this case the enemy was imperfect" closing. It was never going to stay open in the first place.
Thanks for the link, just tried Green Tunnel on the use case where my ISP is blocking me and just managed to change the error from PT_CONNECT_RESET_ERROR to PR_END_OF_FILE_ERROR.
Side note, looks like that if installed by snap on Ubuntu 20.10 it cannot automagically change the proxy configuration in Gnome
green-tunnel:system-proxy [SYSTEM PROXY] error on SetProxy (Error: Command failed: gsettings set org.gnome.system.proxy mode manual
green-tunnel:system-proxy /bin/sh: 1: gsettings: not found
Enabling proxy manually makes it work but yet, it doesn't circumvent my ISP filtering :(
I can't find any source on intra working to prevent SNI sniffing. The page itself only mentions DNS, and Googling doesn't reveal any other source for that.
E: NVM, found it. It does like it uses split hellos.
The correct answer will be reverse, get rid of SNI completely and enforce ESNI everywhere.
Most bad entity now only need to block ESNI, and then the client will happily fallback to plain SNI.
If everyone enforce ESNI only, then it is not gonna going to work.
Just like nowadays, a browser can't view https site is completely useless because most of sites on internet were already encrypted(and the percentage is only going to be more) no matter how useful/useless the site is.
We don't need to kill regular SNI to fix that problem. If a site's DNS record indicates that it supports eSNI, and a connection with eSNI fails, then the browser should hard-fail. And middleboxes can't lie about whether a site supports eSNI, since that's protected by DNSSEC (and it should be coming over DoH anyway). This would break the bad actors without breaking every site that didn't upgrade to eSNI.
As long as plain SNI is still a option, bad actor will try to enforce you to use that. So they can do bad things.
China seems already done that and blocked esni. And the sites eventually gave up esni because people complaining they can't connect to it.
A deprecation likes that(ex. browsers nowaday marks every http site as unsafe) ensure it is not available to everyone. So some sort of these attacks never work.
Do you have a citation for only 10% of internet traffic using CDNs? Even things like cloud load-balances and ephemeral IPs make those associations hard and we’re in third decade of major web properties using CDNs.
[1] https://en.m.wikipedia.org/wiki/Server_Name_Indication