4 ms·

Well, the good point of GoodbyeDPI is exactly so that it preserves your IP address. Normally, when trying to circumvent censorship, you would need a VPN server

Well, the good point of GoodbyeDPI is exactly so that it preserves your IP address. Normally, when trying to circumvent censorship, you would need a VPN server in a different country. But the downsides are that the bank will deny all transactions and call you (OK, answered, they added the VPN IP to the whitelist), that you will miss local-only content, you won't be able to register for a doctor appointment online (the city uses a geo-restricting filter out of security concerns), and you will see foreign prices (which might be 5x higher in some cases!) on sites that differentiate based on the country. Also, extra latency in games. None of that applies with GoodbyeDPI. Edit: the above is written from the viewpoint of the past myself, before emigration to the Philippines.

5e92cb50239222b 4y ago
I wonder why a VPN is the default solution (with all complications it ensues, some of which you've listed), when a simple SSH tunnel to any server in a sane location does just fine. `ssh server -D12345`, point your applications to socks5 at localhost:12345, and it's done. It's dead simple to only allow/deny those sites that you (don't) need to go through another server, and the traffic is encrypted (and optionally compressed), and looks just like another SSH connection. I've used many other solutions (including WireGuard, etc.) on and off, but always come back to SSH.
- userbinator 4y ago
  point your applications to That's the problem. Not all of them will implement tunneling their own traffic through SOCKS, and there's still other things like DNS that you might also want to go through the tunnel, but can't easily do so. A VPN sits at a lower layer, just looking like a regular network connection, so applications don't need to be aware.
  - 5e92cb50239222b 4y ago
    Well, yeah, that's the problem (or the main advantage depending on your viewpoint). The post I was replying to mentioned how painful it is to avoid routing through VPN where it's not needed (although it's pretty easy to do on Linux with network namespaces, and IIRC policy routing, which I've never tried). I just want to point out the simplest solution which for some reason doesn't seem to be very popular, although it covers most users' use-cases better than a VPN connection does (IMHO). Don't know about other browsers, but Firefox is able to send DNS requests through socks, whether you're using DNS-over-HTTPS or not.
- tambourine_man 4y ago
  Thank you, I do too. I though it was only me. SSH is very simple and there’s almost nothing a SSH tunnel can’t do.
  - pelasaco 4y ago
    > SSH is very simple and there’s almost nothing a SSH tunnel can’t do. You cannot disguise your SSH traffic mimicking HTTPS traffic which help you to bypass DPI solutions.. so its easy to block/filter/log your traffic or even pinpoint you in an adverse environment.
    - tambourine_man 4y ago
      Please expand. How can an Apache server, for instance, know if I’m accessing through and SSH tunnel. And how would that be different on a Wireguard VPN?
      - patrakov 4y ago
      - pelasaco 4y ago
        Why apache would care? We are talking about DPI solutions, aka deep packet inspection. They are normally deployed inline, and SSH tunnels are so often blocked, that in some solutions you have it one click away from you https://www.sonicwall.com/support/knowledge-base/how-to-block-ssh-tunneling-proxy-tunneling-using-application-control/170503546461794/ https://www.sonicwall.com/support/knowledge-base/how-to-bloc.... Other solutions try to make the traffic similar with Apache + Firefox to make it harder to be detectable and blocked by DPI solutions..
        tambourine_man 4y ago
        Interesting, thanks. And would Wireguard be transparent to DPI?
- vore 4y ago
  In China at least, the GFW can detect tunneled SSH traffic and cut it off.
- azalemeth 4y ago
  It's easier to detect that someone is using a SOCKS tunnel – from memory, one way it might be exposed is if the packet TTL is incongruous [1] as I don't think SOCKS rewrites those. At the height of the pandemic I travelled to Denmark for work (on a clinical trial) and had a UK negative covid test to report to the UK government that I hadn't got around to – whose website geo-blocks people reporting covid tests from outside a UK IP address (even if, e.g. you'd just left it and wanted to report a negative test taken the day before). A SOCKS proxy was detected and I got a "we cannot verify you are in the UK" message. A wireguard VPN worked fine. [1] https://incolumitas.com/2021/03/13/tcp-ip-fingerprinting-for-vpn-and-proxy-detection/ https://incolumitas.com/2021/03/13/tcp-ip-fingerprinting-for...
- oarsinsync 4y ago
  Encapsulating TCP in TCP results in exponential backoff and retransmissions in the event of loss.
  - deleted 4y ago
    [deleted]
  - patrakov 4y ago
    SSH tunneling is encapsulating byte streams in TCP, not TCP (which means "packets with sequence numbers, acknowledgements, and retransmissions") in TCP, and therefore doesn't suffer.
    - jimmySixDOF 4y ago
      Well the byte stream includes everything you throw in (TCP/UDP/L2), so while the tunnel will not suffer from any signaling issues in the payload flow, the opposite is not true - the internal traffic is affected by any TCP problems on the SSH tunnel so a short blip on the tunnel can cause a cascade of blips depending on whats in there.
mmaunder 4y ago
Why isn’t SSL working for you? You should be end-to-end encrypted and no censor or government should be able to see your https requests. The only time this doesn’t apply is if someone controls your computer or the destination website and is able to MITM your TLS traffic. Is that what has happened? Your HTTPS headers are not visible to anyone. So, for example, why is GoodbyDPI modifying the Host header? This is inside the end-to-end TLS encrypted connection that your ISP can’t see, and that the destination web host can’t see.
- patrakov 4y ago
  SNI (the thing in the ClientHello packet which indicates the domain name for which to get a certificate, just in case if there is more than one SSL website on one IP) is not encrypted. DPI solutions (and even plain old Squid) can look into this without the need to break any encryption.
OmarAssadi 4y ago
For what it’s worth as well, there are other solutions than whole-network VPNs and such. Personally, I chose to generate a domain list for V2Ray from the Russian government’s blocklist when I lived there [1]. I prefer to do that typically because it avoids the pain of the ever-growing whitelists and it allows me to keep the traffic encrypted in case someone does actually figure out that you’ve bypassed DPI. And if you use something like V2Ray or ShadowSocks, they’ll disguise the traffic much better than something like OpenVPN typically would, making it less obvious to anyone monitoring that you’re using a proxy in the first place. There’s a load of references and pre-generated lists for different needs if anyone else is interested in doing something similar [2]. (Also, I hope this doesn’t come across as missing the point of the tool — I think it’s really useful and a good solution. I just figured I’d note some others too) [1]: https://github.com/OmarAssadi/AntiZapret-V2Ray https://github.com/OmarAssadi/AntiZapret-V2Ray [2]: https://github.com/v2ray/domain-list-community https://github.com/v2ray/domain-list-community
- patrakov 4y ago
  The problem with such lists is the inherent assumption that all ISPs block the same "bad stuff". However, in reality, this is not the case, because each ISP has to implement the blocking on their own, and there are multiple DPI solutions with different sets of false positives. This "provider-specific overblocking" is especially common with IPv6. So in addition to using such lists with one of the ISPs, I tried to detect signs of non-prevented blockage using iptables (matching on stuff like unusually-high TTL of an RST packet, or a string that occurs in the SSL certificate that they try to use for MITM - yes, they were not even consistent, or maybe there were two layers of DPI), and add the addresses learned this way to an ipset, so that next time they are routed through a VPN. On the other ISP at a different location, just dropping all packets with ID=0 was for some time enough to avoid the censorship.
- ValdikSS 4y ago
  GoodbyeDPI also includes Russian blacklist built from zapret-info, to apply censorship circumvention only for the websites from the list, to reduce the risk of breaking the website due to mangled traffic. The newest issue are unlisted filtering performed on so-called TSPU DPI boxes. Two years ago we had only ISP DPI boxes, but now there's a government TSPU black box which they control themselves and block the websites/VPNs/SSH/IP ranges out-of-the-registry.

5e92cb50239222b 4y ago

I wonder why a VPN is the default solution (with all complications it ensues, some of which you've listed), when a simple SSH tunnel to any server in a sane location does just fine. `ssh server -D12345`, point your applications to socks5 at localhost:12345, and it's done. It's dead simple to only allow/deny those sites that you (don't) need to go through another server, and the traffic is encrypted (and optionally compressed), and looks just like another SSH connection. I've used many other solutions (including WireGuard, etc.) on and off, but always come back to SSH.

userbinator 4y ago
point your applications to That's the problem. Not all of them will implement tunneling their own traffic through SOCKS, and there's still other things like DNS that you might also want to go through the tunnel, but can't easily do so. A VPN sits at a lower layer, just looking like a regular network connection, so applications don't need to be aware.
- 5e92cb50239222b 4y ago
  Well, yeah, that's the problem (or the main advantage depending on your viewpoint). The post I was replying to mentioned how painful it is to avoid routing through VPN where it's not needed (although it's pretty easy to do on Linux with network namespaces, and IIRC policy routing, which I've never tried). I just want to point out the simplest solution which for some reason doesn't seem to be very popular, although it covers most users' use-cases better than a VPN connection does (IMHO). Don't know about other browsers, but Firefox is able to send DNS requests through socks, whether you're using DNS-over-HTTPS or not.
tambourine_man 4y ago
Thank you, I do too. I though it was only me. SSH is very simple and there’s almost nothing a SSH tunnel can’t do.
- pelasaco 4y ago
  > SSH is very simple and there’s almost nothing a SSH tunnel can’t do. You cannot disguise your SSH traffic mimicking HTTPS traffic which help you to bypass DPI solutions.. so its easy to block/filter/log your traffic or even pinpoint you in an adverse environment.
  - tambourine_man 4y ago
    Please expand. How can an Apache server, for instance, know if I’m accessing through and SSH tunnel. And how would that be different on a Wireguard VPN?
    - patrakov 4y ago
    - pelasaco 4y ago
      Why apache would care? We are talking about DPI solutions, aka deep packet inspection. They are normally deployed inline, and SSH tunnels are so often blocked, that in some solutions you have it one click away from you https://www.sonicwall.com/support/knowledge-base/how-to-block-ssh-tunneling-proxy-tunneling-using-application-control/170503546461794/ https://www.sonicwall.com/support/knowledge-base/how-to-bloc.... Other solutions try to make the traffic similar with Apache + Firefox to make it harder to be detectable and blocked by DPI solutions..
      - tambourine_man 4y ago
        Interesting, thanks. And would Wireguard be transparent to DPI?
vore 4y ago
In China at least, the GFW can detect tunneled SSH traffic and cut it off.
azalemeth 4y ago
It's easier to detect that someone is using a SOCKS tunnel – from memory, one way it might be exposed is if the packet TTL is incongruous [1] as I don't think SOCKS rewrites those. At the height of the pandemic I travelled to Denmark for work (on a clinical trial) and had a UK negative covid test to report to the UK government that I hadn't got around to – whose website geo-blocks people reporting covid tests from outside a UK IP address (even if, e.g. you'd just left it and wanted to report a negative test taken the day before). A SOCKS proxy was detected and I got a "we cannot verify you are in the UK" message. A wireguard VPN worked fine. [1] https://incolumitas.com/2021/03/13/tcp-ip-fingerprinting-for-vpn-and-proxy-detection/ https://incolumitas.com/2021/03/13/tcp-ip-fingerprinting-for...
oarsinsync 4y ago
Encapsulating TCP in TCP results in exponential backoff and retransmissions in the event of loss.
- deleted 4y ago
  [deleted]
- patrakov 4y ago
  SSH tunneling is encapsulating byte streams in TCP, not TCP (which means "packets with sequence numbers, acknowledgements, and retransmissions") in TCP, and therefore doesn't suffer.
  - jimmySixDOF 4y ago
    Well the byte stream includes everything you throw in (TCP/UDP/L2), so while the tunnel will not suffer from any signaling issues in the payload flow, the opposite is not true - the internal traffic is affected by any TCP problems on the SSH tunnel so a short blip on the tunnel can cause a cascade of blips depending on whats in there.

mmaunder 4y ago

Why isn’t SSL working for you? You should be end-to-end encrypted and no censor or government should be able to see your https requests. The only time this doesn’t apply is if someone controls your computer or the destination website and is able to MITM your TLS traffic. Is that what has happened? Your HTTPS headers are not visible to anyone. So, for example, why is GoodbyDPI modifying the Host header? This is inside the end-to-end TLS encrypted connection that your ISP can’t see, and that the destination web host can’t see.

patrakov 4y ago
SNI (the thing in the ClientHello packet which indicates the domain name for which to get a certificate, just in case if there is more than one SSL website on one IP) is not encrypted. DPI solutions (and even plain old Squid) can look into this without the need to break any encryption.

OmarAssadi 4y ago

For what it’s worth as well, there are other solutions than whole-network VPNs and such. Personally, I chose to generate a domain list for V2Ray from the Russian government’s blocklist when I lived there [1]. I prefer to do that typically because it avoids the pain of the ever-growing whitelists and it allows me to keep the traffic encrypted in case someone does actually figure out that you’ve bypassed DPI. And if you use something like V2Ray or ShadowSocks, they’ll disguise the traffic much better than something like OpenVPN typically would, making it less obvious to anyone monitoring that you’re using a proxy in the first place. There’s a load of references and pre-generated lists for different needs if anyone else is interested in doing something similar [2]. (Also, I hope this doesn’t come across as missing the point of the tool — I think it’s really useful and a good solution. I just figured I’d note some others too) [1]: https://github.com/OmarAssadi/AntiZapret-V2Ray https://github.com/OmarAssadi/AntiZapret-V2Ray [2]: https://github.com/v2ray/domain-list-community https://github.com/v2ray/domain-list-community

patrakov 4y ago
The problem with such lists is the inherent assumption that all ISPs block the same "bad stuff". However, in reality, this is not the case, because each ISP has to implement the blocking on their own, and there are multiple DPI solutions with different sets of false positives. This "provider-specific overblocking" is especially common with IPv6. So in addition to using such lists with one of the ISPs, I tried to detect signs of non-prevented blockage using iptables (matching on stuff like unusually-high TTL of an RST packet, or a string that occurs in the SSL certificate that they try to use for MITM - yes, they were not even consistent, or maybe there were two layers of DPI), and add the addresses learned this way to an ipset, so that next time they are routed through a VPN. On the other ISP at a different location, just dropping all packets with ID=0 was for some time enough to avoid the censorship.
ValdikSS 4y ago
GoodbyeDPI also includes Russian blacklist built from zapret-info, to apply censorship circumvention only for the websites from the list, to reduce the risk of breaking the website due to mangled traffic. The newest issue are unlisted filtering performed on so-called TSPU DPI boxes. Two years ago we had only ISP DPI boxes, but now there's a government TSPU black box which they control themselves and block the websites/VPNs/SSH/IP ranges out-of-the-registry.