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

61–70 of 124 posts

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#61

Post by wruza »

liberia wrote: post #2

Worth reading Deep Packet Inspection is Dead: https://security.ias.edu/deep-packet-inspection-dead-and-her... This tool is great, but I religiously route all my traffic through a VPN that I own and control. I’ve hardened the box I use to have zero logs and I don’t need to blindly trust a commercial provider whether they’ve been audited or not. There’s no way of really knowing they’re not logging in some capacity bar…

religiously route all my traffic through a VPN that I own and control

Can you please share an easy way to do that?

I’m usually not afraid of wading through configuration swamps, but when it comes to openvpn, I curl up in a corner crying.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#62

Post by Zen1th »

wruza wrote: post #61
liberia wrote: post #2

Worth reading Deep Packet Inspection is Dead: https://security.ias.edu/deep-packet-inspection-dead-and-her... This tool is great, but I religiously route all my traffic through a VPN that I own and control. I’ve hardened the box I use to have zero logs and I don’t need to blindly trust a commercial provider whether they’ve been audited or not. There’s no way of really knowing they’re not logging in some capacity bar…

religiously route all my traffic through a VPN that I own and control Can you please share an easy way to do that? I’m usually not afraid of wading through configuration swamps, but when it comes to openvpn, I curl up in a corner crying.

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.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#63

Post by [deleted] »

oarsinsync wrote: post #59
5e92cb50239222b wrote: post #26

Earlier quoted context omitted.

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

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

[deleted]

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#64

Post by witrak »

psydvl wrote: post #60
kebman wrote: post #57

Sorry, might be a dumb question, but isn't this simply a matter of encrypting your packets or using a VPN?

Default user just want to access blocked resources. Free VPN... Can we trust them? Paid VPN are paid.

>Free VPN... Can we trust them? Paid VPN are paid.

Paid VPNs are paid. Can we trust them more?

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#65

Post by pklack »

luke727 wrote: post #56
buwrtgu wrote: post #14

Earlier quoted context omitted.

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

"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-mainline Linux kernel with secure boot enabled. Just enroll your own Certificate and (automate the process to) sign binaries yourself. I really wonder why no one yet started some kind of project to provide a "community trust root" of some sorts which you could enroll on your machine.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#66

Post by gjulianm »

progbits wrote: post #37
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?

Censorship companies probably can't hire good talent. I'm actually glad to see this, however it might get patched if this tool becomes too widespread.

It's not as much about talent but about tradeoffs. I work in traffic monitoring tools (not censorship, just observability tools for infrastructure) there's always the decision of how many edge cases you want to cover vs how fast you want your tool to go. At millions of packets per second, an extra "if" might make a big difference in the throughput you're able to monitor. So maybe it's actually reasonable to ignore the .1% that use "hoSt" instead of "Host" to avoid losing .5% of the packets.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#67

Post by vlovich123 »

Ekaros wrote: post #51
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?

It is harder problem that it sounds. Deep packet inspection needs to happen at some linespeed. More work you do the harder it is to process it all fast enough. You can write stuff for single packets, but when you have lot of connections happening it becomes much harder problem.

Isn’t this stuff typically specially built HW? I feel like an ASIC can accelerate this stuff fairly quickly although the volumes/pricing may not warrant building that. Also if you’re matching on host name there’s no reason you even need to keep up with line rate. All you need is to do is keep up with the connection establishment rate and you can always do the processing in the background and just issue a TCP reset after the fact.

Re: GoodbyeDPI: Deep Packet Inspection circumvention utility

#70

Post by vbezhenar »

vlovich123 wrote: post #67
Ekaros wrote: post #51

Earlier quoted context omitted.

It is harder problem that it sounds. Deep packet inspection needs to happen at some linespeed. More work you do the harder it is to process it all fast enough. You can write stuff for single packets, but when you have lot of connections happening it becomes much harder problem.

Isn’t this stuff typically specially built HW? I feel like an ASIC can accelerate this stuff fairly quickly although the volumes/pricing may not warrant building that. Also if you’re matching on host name there’s no reason you even need to keep up with line rate. All you need is to do is keep up with the connection establishment rate and you can always do the processing in the background and just issue a TCP reset af…

Can you update ASICs with new firmware?
Post reply on HN