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

Circumventing Deep Packet Inspection with Socat and Rot13

gist.github.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#11

Post by usr1106 »

jortr0n wrote: post #5
usr1106 wrote: post #3

So once the maintainers of the deep packet inspection software read this they will add rot13 to their code.

The use of rot13 was just an amusement in this case given its vintage. Replacing rot13 with any other simple stdin/stdout transcoder should be simple to do via the socat invocation, eg base64, a sed replace command, gzip/gunzip, even an actual symmetric encryption protocol like AES, etc.

So if you contol both ends any kind of obfuscation will defeat deep packet inspection, as long as the same obfuscation is not widely used so that the inspection software can check for it.

But if you do not control both ends, let's say you want many customers or even the public to connect to your server that's not an option.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#12

Post by throw0101a »

In case someone is not aware, socat allows for TLS connections with the OPENSSL-LISTEN and OPENSSL options:

* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...

* http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPE...

Just create a self-signed certificate:

    openssl req -newkey rsa:2048 -nodes -keyout socat.key -x509 -days 1000 \
        -subj '/CN=www.mydom.com/O=My Company Name LTD./C=US' -out socat.pem
for the server and tell the client not to check ("verify=0").

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#13

Post by xchaotic »

xmcqdpt2 wrote: post #7
usr1106 wrote: post #3

So once the maintainers of the deep packet inspection software read this they will add rot13 to their code.

The author only used rot13 to make a point about the failure mode of inspection. DPI is only there to stop everyday employees from bypassing security policies inadvertently, not to stop an actual attacker. An attacker could use any number of other approaches: hiding payloads in innocuous keywords, using actual encryption, steganography, what have you. I'm not a security expert but we had those kind of measures at a p…

I don’t get the scenario he tested where he has access to both sides and can freely install cyphers on the server and what not. If you have just installed vpn endpoint and send whatever packets you feel like.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#14

Post by MadsRC »

I love this! Using a 2000+ year cipher to circumvent Deep Packet Inspection seems almost poetic.

I feel like the article missed out on mentioning one key thing: Using a deny-list doesn’t work. It’s much more viable to default block and allow the stuff you know you’ll allow. Defaulting to allow and blocking stuff you don’t want is how you end up being owned by rot13.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#15

Post by largbae »

xchaotic wrote: post #13
xmcqdpt2 wrote: post #7

Earlier quoted context omitted.

The author only used rot13 to make a point about the failure mode of inspection. DPI is only there to stop everyday employees from bypassing security policies inadvertently, not to stop an actual attacker. An attacker could use any number of other approaches: hiding payloads in innocuous keywords, using actual encryption, steganography, what have you. I'm not a security expert but we had those kind of measures at a p…

I don’t get the scenario he tested where he has access to both sides and can freely install cyphers on the server and what not. If you have just installed vpn endpoint and send whatever packets you feel like.

I think the point is that the perimeter security doesn't provide the security that the client imagined. Gaining root on any endpoint in the network (and then finding an endpoint you can control anywhere else on the internet) gives you a way in and out of the company network.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#16

Post by Brian_K_White »

vermilingua wrote: post #4
usr1106 wrote: post #3

So once the maintainers of the deep packet inspection software read this they will add rot13 to their code.

Which would slow down inspection by a factor of 25 if it were to check the whole keyspace.

There is no special limit of 25 possible keys.

The keyspace is essentially infinite, because of 2 things:

1 you don't have to worry about control bytes (aka "binary")

2 unicode

rot13 using 1/2 of the 26 letter English a-z alphabet is just an arbitrary limit for visual appearance and limitation of the channel in bbs/newsgroup posts.

Things like rot18 and rot47 already widen the alphabet significantly up from 26 to include numbers, punctuation, and more of the "printable" ascii from 0-127, while still avoiding control bytes like null etc.

But this example is using rot13 in a channel passing binary data already, so there is no point avoiding the control bytes like null etc.

So without going to unicode the limit would already be 255.

But the alphabet, and thus the key space, is practically infinite with unicode. Merely your bandwidth goes down when you get to say, 16 encoded bytes per plaintext byte.

In fact, you don't even need to bother 'rotating' anything, you can just pick a random number anywhere from 1 to the zillions, and simply add that number to the plaintext values and subtract from the ciphertext. Rather than rotating, it's just transposing, but that's all rotating is anyway.

You don't even need to install any package like bsdgames either. You can do the encode/decode directly in bash, not even very many lines.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#18

Post by sporksmith »

Folks interested in the state of the art of this kind of DPI evasion might want to check out obs4, which is a "look-like nothing obfuscation protocol", and the default pluggable transport for connecting to tor bridges from places where tor is blocked.

obs4: https://github.com/Yawning/obfs4

obs4 in tor: https://support.torproject.org/glossary/obfs4/

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#19

Post by Thiez »

usr1106 wrote: post #11
jortr0n wrote: post #5

Earlier quoted context omitted.

The use of rot13 was just an amusement in this case given its vintage. Replacing rot13 with any other simple stdin/stdout transcoder should be simple to do via the socat invocation, eg base64, a sed replace command, gzip/gunzip, even an actual symmetric encryption protocol like AES, etc.

So if you contol both ends any kind of obfuscation will defeat deep packet inspection, as long as the same obfuscation is not widely used so that the inspection software can check for it. But if you do not control both ends, let's say you want many customers or even the public to connect to your server that's not an option.

> as long as the same obfuscation is not widely used so that the inspection software can check for it.

I imagine there are only so many things you can detect with DPI before the network connection becomes (even more) prohibitively slow. And you can check for rot13 or base64 or common compression algorithms (but beware of zip bombs), but you can't check for properly encrypted data since it will appear as random bits.

Post reply on HN