Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GoodbyeDPI: Deep Packet Inspection circumvention utility

github.com

Post reply on HN
Print view View original

91–100 of 124 posts

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#91

Post by grishka »

Avamander wrote: post #86
laughinghan wrote: post #20

Earlier quoted context omitted.

That's what domain fronting is for, and even though the GFW attempts to filter by SNI, genetic algorithms like Geneva are able to find workarounds: https://geneva.cs.umd.edu/papers/foci21.pdf

ESNI/ESH is coming soon, I guess we'll see soon enough how that plays out.

Since the project at the OP link is mostly/initially aimed at Russia, in my own experience, it's not always just DPI — it's often DPI combined with a firewall. Roskomnadzor can order to block access to a domain, but then they can also specify an IP or a subnet instead. For example, that's what happened when they tried to block Telegram, which does not use DNS at all.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#94

Post by pelasaco »

rixrax wrote: post #33

Looking at the circumvention techniques GoodbyeDPI uses makes me want to cry. Is this really the state of DPI in 2022: changing Host to hoSt, or adding white spaces between method and URI actually works?

most the engines out there weren't made for security but performance. It's disturbing and relaxing at the same time to see how easy it is to bypass them. Something that works 100% is to multiplex a channel, changing it protocols after some packages. You do the SSL handshake, than after some amount of time, you switch it to SSH, I think something like that https://github.com/yrutschle/sslh (couldn't find the real repository that I used, but that one looks similar) could be used after the detection to bypass filters

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#95

Post by patrakov »

mmaunder wrote: post #72
patrakov wrote: post #18

Earlier quoted context omitted.

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 (th…

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…

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.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#96

Post by patrakov »

OmarAssadi wrote: post #75
patrakov wrote: post #18

Earlier quoted context omitted.

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 (th…

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 yo…

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.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#97

Post by dicknuckle »

wruza wrote: post #77
Zen1th wrote: post #62

Earlier quoted context omitted.

Personally I use dsvpn ( https://github.com/jedisct1/dsvpn ) which is super simple to setup and use, and it's made by the guy who created libsodium.

Thanks! But from what I can see in sources (please correct me if that’s wrong), it is not a vpn, and a regular vpn client cannot connect to it. Nice idea along the lines of SOCKS proxy.

You can just use Tailscale if all of this seems like a pushup. It's wireguard under the hood and everything JustWorks™

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#98

Post by ValdikSS »

userbinator wrote: post #7

Looks like it uses WinDivert as the filtering driver, which says on its site that "Windows Server 2016 systems must have secure boot disabled"; not entirely surprising and a reminder of what a lot of the "security" stuff is really securing.

Windows Server 2016+ with Secure Boot enabled won't allow loading of any third-party non-HLK-certified drivers, whether they are signed or unsigned. That's why.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#99

Post by ValdikSS »

buwrtgu wrote: post #14
userbinator wrote: post #7

Looks like it uses WinDivert as the filtering driver, which says on its site that "Windows Server 2016 systems must have secure boot disabled"; not entirely surprising and a reminder of what a lot of the "security" stuff is really securing.

"secure boot must be disabled" is the equivalent of "in case of permissions error, just chmod 777". secure boot literally protects the user first, and is configurable with user provided keys on the vast vast majority of open platform computers (i.e. amd64) "prevent injection of a driver that can divert all my shit at the kernel level" is exactly what you want secure boot protecting you from. there is no limitation of…

Windows Server 2016+ with Secure Boot enabled won't allow loading of any third-party non-HLK-certified drivers, whether they are signed or unsigned. That's why.

And HLK is only for device drivers, not for any regular drivers, as far as I know.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#100

Post by marwis »

pklack wrote: post #65
luke727 wrote: post #56

Earlier quoted context omitted.

"prevent injection of a driver that can divert all my shit at the kernel level" is exactly what you want secure boot protecting you from. The only thing Secure Boot is doing here is preventing you from loading a driver not blessed by Microsoft. They would happily bless "a driver that can divert all my shit at the kernel level", but it costs too much for the maintainer of WinDivert.

It is kind of sad that no one seems to bother enough to actually learn how to use Secure Boot to their advantage. Everyone is just disabling it the first time it gets in their way. Reminds me of how Firewalls used to be treated like 20 years ago. Yes, by default most implementations will only accept signatures from Microsoft. But the thing is: You can always enroll your own keys. My Laptop is currently booting a non-…

Would it really help in this case? I believe the HLK-signing is enforced by Windows, not UEFI. Uploading your own cert to UEFI won't change that.
Post reply on HN