
GoodbyeDPI – Passive Deep Packet Inspection Blocker / Circumvention Utility - eternalny1
https://github.com/ValdikSS/GoodbyeDPI
======
tptacek
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/](https://www.monkey.org/~dugsong/fragroute/)

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

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

~~~
windexh8er
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](https://noxxi.de/research/http-evader.html)

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

~~~
Jordanpomeroy
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?

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

------
parliament32

        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.

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

~~~
ValdikSS
>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](https://github.com/ValdikSS/blockcheck)

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

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

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

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

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

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

------
ausjke
[https://github.com/bol-van/zapret](https://github.com/bol-van/zapret) has a
linux version

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

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

~~~
ValdikSS
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...](https://ntc.party/c/internet-censorship-all-around-the-world/russia)

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

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

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

~~~
insulanus
Thanks. We need to know this type of information!

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

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

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

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

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

Isn't DPI used to block VPNs?

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

