5 ms·

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 awa

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) [1] https://en.m.wikipedia.org/wiki/Server_Name_Indication https://en.m.wikipedia.org/wiki/Server_Name_Indication

jgrahamc 6y ago
About getting rid of SNI... https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/ Been working on that also.
- darkwater 6y ago
  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.
ignoramous 6y ago
You can bypass SNI inspection [0] with tools like GreenTunnel [1] and Intra [2]. [0] https://twitter.com/vinifortuna/status/1304189371688660992 https://twitter.com/vinifortuna/status/1304189371688660992 [1] https://news.ycombinator.com/item?id=22654737 https://news.ycombinator.com/item?id=22654737 [2] https://getintra.org/ https://getintra.org/
- d3nj4l 6y ago
  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.
  - deleted 6y ago
    [deleted]
- darkwater 6y ago
  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 :(
  - ignoramous 6y ago
    Does Intra work?
judge2020 6y ago
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. 0: https://news.ycombinator.com/item?id=25314182 https://news.ycombinator.com/item?id=25314182
- sroussey 6y ago
  Yeah, but that argument sounds like asking people to use “logmein” as a password so they don’t need to install MDM on everything. Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).
  - Kalium 6y ago
    I think you've nailed the core of it. 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.
- ReactiveJelly 6y ago
  > 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.
- mindslight 6y ago
  > 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.
throwaway54235 6y ago
No! Solving the SNI problem is far from enough. The server IP address can be easily correlated with the domain for 90% of Internet traffic.
- acdha 6y ago
  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.
mmis1000 6y ago
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.
- josephcsible 6y ago
  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.
  - mmis1000 6y ago
    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.
pcwrt 6y ago
Use a VPN then.

jgrahamc 6y ago

About getting rid of SNI... https://blog.cloudflare.com/encrypted-client-hello/ https://blog.cloudflare.com/encrypted-client-hello/ Been working on that also.

darkwater 6y ago
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.

ignoramous 6y ago

You can bypass SNI inspection [0] with tools like GreenTunnel [1] and Intra [2]. [0] https://twitter.com/vinifortuna/status/1304189371688660992 https://twitter.com/vinifortuna/status/1304189371688660992 [1] https://news.ycombinator.com/item?id=22654737 https://news.ycombinator.com/item?id=22654737 [2] https://getintra.org/ https://getintra.org/

d3nj4l 6y ago
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.
- deleted 6y ago
  [deleted]
darkwater 6y ago
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 :(
- ignoramous 6y ago
  Does Intra work?

judge2020 6y ago

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. 0: https://news.ycombinator.com/item?id=25314182 https://news.ycombinator.com/item?id=25314182

sroussey 6y ago
Yeah, but that argument sounds like asking people to use “logmein” as a password so they don’t need to install MDM on everything. Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).
- Kalium 6y ago
  I think you've nailed the core of it. 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.
ReactiveJelly 6y ago
> 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.
mindslight 6y ago
> 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.

throwaway54235 6y ago

No! Solving the SNI problem is far from enough. The server IP address can be easily correlated with the domain for 90% of Internet traffic.

acdha 6y ago
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.

mmis1000 6y ago

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.

josephcsible 6y ago
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.
- mmis1000 6y ago
  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.

pcwrt 6y ago

Use a VPN then.