Hacker News Reader

Comment by patrakov | Hacker News Reader

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.

View on HN

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.

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

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.

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.

In China at least, the GFW can detect tunneled SSH traffic and cut it off.

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.

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

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?

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-bloc.... Other solutions try to make the traffic similar with Apache + Firefox to make it harder to be detectable and blocked by DPI solutions..

Interesting, thanks. And would Wireguard be transparent to DPI?

there are many implementations of DPI out there, each one with your own set of rules and heuristics... this discussion[1] talks about it, but the short answer is: it depends

References:

[1] https://www.reddit.com/r/WireGuard/comments/ajv0eq/wireguard...

@patrakov I can't reply to you directly.

If the only thing a web server could do is differentiate tunnel from direct IP connection with or without firewall/NAT, which are ubiquitous, it's an interesting effort, but a tour de force with little gain IMO.

Encapsulating TCP in TCP results in exponential backoff and retransmissions in the event of loss.

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.

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.

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

[2]: https://github.com/v2ray/domain-list-community

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.

Yeah, I've come across your tool a few times before and seen the default lists. Really useful stuff, by the way!

Interesting, though. I had heard talks about introducing proper government-level filtering -- I think after the Telegram/AWS/etc blocks in, like, 2018 (?), but I wasn't aware of anything actually going into effect.

If you've got time to answer or link me anything, I am a little curious. How are the TSPU boxes setup? Are these provided by the government to different datacenters/IXs or at some sort of higher level than that? And are they currently just used to filter additional out-of-registry domains/IP addresses or do they also filter the semi-public, known blacklist? Is there anything like the unofficial Chinese gfwlist that tries to maintain a list of the out-of-registry stuff?

I haven't lived in Russia in a little while now, but when I was last there, although virtually every residential ISP enforced the government list, a number of the domestic server providers weren't, so a good option for low-latency and keeping a Russian IP address was just renting a gigabit VPS from the city next to me and using it as a proxy server.

https://bitbucket.org/anticensority/russian-unlisted-blocks/... — my list of unlisted blocks

>How are the TSPU boxes setup? Are these provided by the government to different datacenters/IXs or at some sort of higher level than that?

They are provided by the government and should be installed topologically close to the client, before CGNAT. This is a modified RDP.RU EcoFilter, and currently are required to be installed only on residential connections, not in DCs/IXes. ISPs do not have any configuration access, and it's prohibited to route traffic not via the boxes. The abbreviation TSPU means Technical Measures to Combat Threats, and these boxes are capable of collecting, saving and centralized sharing of NetFlow data, but currently are almost always used only for blocking, however the general idea is to centrally control BGP flows and collect SNMP data from other ISP routers.

The company which controls the boxes is called Center of Public Network Monitoring and Control (ЦМУ ССОП, Центр мониторинга и управления сетью связи общего пользования).

>do they also filter the semi-public, known blacklist?

Yes, they do. I suppose the idea is to replace filtering DPI boxes which were installed on the ISP network all these years with this one. Right now most ISPs have both TSPU and one of commercial DPI systems.

More information in English from Alexander Isavnin on RIPE: https://ripe83.ripe.net/archives/video/630/

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.

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.

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.

Reply on news.ycombinator.com