GoodbyeDPI – Passive Deep Packet Inspection Blocker / Circumvention Utility | Hacker News Reader

GoodbyeDPI – Passive Deep Packet Inspection Blocker / Circumvention Utility

github.com

112 pointsEMM_38643 comments

So... this is basically fragrouter? [1]

If so, this is a very old idea (I, uh, co-invented it?). A lot of DPI gear isn't built for serious security, but rather best effort, and I'm sure basic TCP tricks like this will bypass those. But you should be aware that serious, modern middleboxes were very definitely built with knowledge of fragrouter-type tricks (and of evasion more generally), and you're better off using a VPN than relying on stuff like this if your evasion actually matters from an opsec perspective.

[1]: https://www.monkey.org/~dugsong/fragroute/

I think DPIs might also be used to detect VPNs. I'm not familiar with VPN traffic patterns situation but I doubt that it's too chaotic or masquerades as something else, since VPNs weren't invented with DPI in mind.

Not to imply that GoodbyeDPI assuages all my doubts, either.

DPI can certainly be used to detect VPNs, but my broader point is, if you want real assurance, you need to get a VPN working; you can't rely on TCP/IP reassembly glitches, because they're largely addressable by the serious DPI vendors.

I think it's right to say you can't rely on those older methods, but there has been a lot of research that's gone into DPI bypass. The HTTP Evader work that's been done is particularly good [0]. In some cases the guarantee of operating a VPN over a hostile network isn't guaranteed, especially something like IPsec. So it's good that the simplistic fragmentation methods of tools like fragrouter have been expanded on.

[0] https://noxxi.de/research/http-evader.html

The stuff HTTP Evader is doing is simpler still than the stuff fragrouter (and this tool) does. Middlebox evasion is a cat and mouse game. I'm fine with people playing that game, but not with their lives; if real opsec is on the line, you need a VPN.

Sorry, n00b here, but a friend was telling me about a new version of Internet Protocol that fixes man in the middle attacks, like deep packet inspection. Is that realistically coming anytime soon?

It is an impossibility. Protocols are layered and so at one layer you can add features to detect possible MITM (eg. IPSec, SSL etc.) but cannot always be eliminated.

I suggest you consult a book like "The TCP/IP Guide" to get an overview of the main data protocols and how they work. In this day and age, everybody ought to know something about the basic protocols which form the bedrock of our networked society.

Detecting VPNs is not an issue in most places since VPNs are allowed.

> So... this is basically fragrouter?

No, not really. GoodbyeDPI does not perform IP-level fragmentation, it does not generate/send any packets at all, it only modifies them or drop them.

What's called "Fragmentation" in GoodbyeDPI is TCP Window Size shrinking, to force OS to send TCP packets of small size.

I'm aware of fragroute, and I have plans to implement some of its techniques in GoodbyeDPI.

Fragrouter, and the paper it's based off of, does a bunch of TCP manipulation; "frag" is just a shorthand.

    TCP-level fragmentation for first data packet
    TCP-level fragmentation for persistent (keep-alive) HTTP sessions
    Replacing Host header with hoSt
    Removing space between header name and value in Host header
    Adding additional space between HTTP Method (GET, POST etc) and URI
    Mixing case of Host header value

Very interesting. This is, of course, depending on the DPI-blocking application to be pretty poorly engineered, but I wouldn't be surprised. I'd be interested to see which national DPI solutions (GFC, Russia) this successfully circumvents, not just commercial products.

I'd also be quite interested in knowing which queries are detected and whether different tools have any effect, but pretty sure that it's a black-box situation where something can be surmised only if the DPI is in the binary mode of ‘block/pass.’ IMO in fact there might be a gray zone of ‘mark this dude as suspicious’ with an unpleasant prospect of future non-digital trouble.

>I'd also be quite interested in knowing which queries are detected and whether different tools have any effect

For that, I wrote Blockcheck utility to check whether censorship circumvention techniques could be applied on this ISP or not.

https://github.com/ValdikSS/blockcheck

GoodbyeDPI was working until April this year. After that Turkish Telekоm must have updated its evil softwares because this tool is not useful anymore.

I have an experimental version which works with Turk Telecom. Contact me if you want to test it.

> TCP-level fragmentation for first data packet && TCP-level fragmentation for persistent (keep-alive) HTTP sessions

> I'd be interested to see which national DPI solutions (GFW, Russia) this successfully circumvents

The GFW seems to do TCP stream reassembly. I don't think this will work in China.

INTANG should work https://github.com/seclab-ucr/INTANG

I have plans to implement INTANG methods in GoodbyeDPI, but it requires some architectural changes first.

Modern DPIs in Russia also perform stream reassembly or at least have proper state machine, so they can't be circumvented that easily anymore, unfortunately.

This is Windows-only. The code claims to be userland but relies on kernel middleware. That is interesting, because the driver seems to be signed. If you've never looked at Windows kernel stuff, you'd probably be surprised at:

1) How much it looks like *nix. 2) How hard it is to actually use your own code.

> Windows Server 2016 systems must have secure boot disabled.

That's no good.

> How hard it is to actually use your own code.

What do you mean by this? It's easy enough with test-signing. Just use SignTool sign to sign your binary. Then sc create to create the service for the driver, and sc start to start it as usual.

> How much it looks like 'nix.

Also not sure what you mean by this either... to me there's a world of difference between Windows and 'nix kernel development.

Test signing isn't meant to be used on a real system. You're intended to have an entirely separate test cluster or at least test machine. There are usability downsides to this, many of them cosmetic, but one major one is you need to disable secure boot. In some cases (this may have changed) you could only enable test signing for the next boot meaning you had to constantly keep re-enabling it.

Overall very user hostile, and it leaves one with the impression they don't want you to run your own code or let other people run your code without paying protection money.

For the other part... go look at the driver documentation. The names are different but the patterns are all the same except for a few places.

Okay then I don't get it. What even is the point of secure boot when your entire goal is to run arbitrary kernel mode code? You're effectively always running in test-signing mode on Linux -- your entire goal is to be able to run your own modules, which is what test-signing mode does. And if you want to be in that situation, you can permanently enable it with bcdedit; there's no need to constantly toggle it.

If your complaint is that you have to cough up $$$ to have your driver be trusted by other users' machines, yeah, I'm happy to rant about that issue, but that's not an issue with the "difficulty" of the process. That's like saying it's hard to use a Lamborghini because it's too expensive.

As for the names and patterns... idk, it's hard for me to see what's similar, except that both systems have file systems, both have handles/descriptors, etc... which is hardly an interesting point. Everything from the way you hook I/O to the way syscalls are handled to the quality of the documentation is vastly different on each system.

> What even is the point of secure boot when your entire goal is to run arbitrary kernel mode code?

Err, it's code I wrote, or code I am likely to be familiar with? My issue isn't with the feature of driver signing but its application. I can choose to be in test signing mode on Linux or not, and if I am, it doesn't gimp the system in arbitrary ways.

Look again, Windows is like a black box over a rewritten Unix kernel. It's kind of funny. It took a while for it to click.

> My issue isn't with the feature of driver signing but its application. I can choose to be in test signing mode on Linux or not, and if I am, it doesn't gimp the system in arbitrary ways.

I don't know what "gimp the system in arbitrary ways" means. I've been running Windows in test-signing mode for years with no problem. Microsoft doesn't officially bless it, but that doesn't exactly matter in any material way.

https://github.com/bol-van/zapret has a linux version

Just installed it a couple days ago. I'm surprised that it still works in Russia.

Having worked on a library that was often used in DPI (security systems, not national-level censorship stuff, although after open-sourcing we lost the power to discriminate) I would not imagine that simple fragmentation, insertion of spaces nor mixed-case would do all that much to slow down a well-written DPI system.

I suspect more elaborate evasions might necessary - e.g. tcp fragmentation with inconsistent fragments where the understanding of which final 'reassembly' the target gets is necessary to understand what the DPI system is seeing. This might also ring alarm bells at the intermediate firewall, though. The problem is with the censorship firewalls is that they can just throw stuff on the floor if they feel a bit suspicious about it; they can be inherently 'worse' in their liveness guarantees than, say, a corporate DPI product.

In Russia, DPI systems which are used for censorship generally prevent accessing only blocked domain names or exact HTTP URLs. There's no proxy or VPN censorship in place, so unknown protocols are not getting discarded.

We still don't have national-wide firewall like that in China, each ISP (and we have 1000+ of them) performs censorship using either dumb IP blackholing (breaks a lot of legitimate stuff), on-path DPI (I call it "passive" in GoodbyeDPI, DPI which receive mirrored traffic and can only inject something but not prevent the connectivity per se), in-path DPI (DPI as a router/bridge).

Most DPI systems in Russia were specifically created for Russian censorship (i.e. capable only for HTTP URL and TLS SNI introspection), from scratch. Some ISP have their own in-house DPI systems. These systems were just not designed to handle packets fragmented on TCP or IP level at the beginning, because it's rarely the case in the real world.

If you want to learn more, visit internet censorship forum I created. I write about different DPI systems there and trying to document internet censorship in Russia as a whole. https://ntc.party/c/internet-censorship-all-around-the-world...

So, can this be used in conjunction with OpenVPN? My phone carrier has silently started block my VPN connection when tethering.

It it a national carrier? Name and shame, please!

AT&T. Stopped in January of this year for apparently no reason. I can even ssh into my home computer, but my work vpn just hangs.

Thanks. We need to know this type of information!

Probably. I know that people use GoodbyeDPI on MTS mobile career in Russia, to circumvent tethering restrictions.

Without GoodbyeDPI, the career introspects HTTP User-Agent header and the internet gets blocked if it looks like a PC user agent. With GoodbyeDPI, career systems break and could not introspect the user agent header.

This is a specific technique, designed to confound a specific DPI method. It is not a generic blocker, or circumvention, as I understand IPSEC or IP in IP or IP over ICMP or IP over DNS or any of a number of tunnelling and encryption mechanisms.

The name is misleading: its a shield, for one weapon. Its not armour against all weapons

Just out of curiosity, can anyone from China verify if it works? (for now)

Edit: my concern is that the engineers at GFW might quickly upgrade their system to target it.

Most Chinese use VPN or other tunnel protocols these days. Once GFW finds out you are using a VPN or tunnel, it will block the TCP/UDP connection by dropping packets. And it does can identify any protocol that is widely used, even those claim to have obfuscation ability, like shadowsocks.

Anyway, the TCP/HTTP tricks discussed here may work for some time or not, but we really do not expect much from that.

It doesn't, but INTANG should.

https://github.com/seclab-ucr/INTANG

Isn't it better to just use a VPN? The Chinese have been doing that for years.

> Isn't it better to just use a VPN? The Chinese have been doing that for years.

Isn't DPI used to block VPNs?

Yes, but the Chinese have also been fighting it for about as long --- https://en.wikipedia.org/wiki/Shadowsocks and obfsproxy being the two that immediately come to mind.

VPNs are easily detected and can be throttled. Also they're slow af. This would allow you to use your full internet speed and bypass filters.

If you haven’t, I recommend trying a VPN that supports Wireguard sometime. It is a lot faster and lower latency for me.

Wireguard is not designed for bypass firewalls. The protocol has significant patterns, and already been blocked by the GFW. (you will find it if you use it often)

Sure, but “easily detected” and “slow af” need not be true simultaneously.

Reply on news.ycombinator.com