Live data from Hacker News

Circumventing Deep Packet Inspection with Socat and Rot13

gist.github.com

21–30 of 39 posts

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#21
Not at all the main point, but tr can do rot13 and more; plus GNU Coreutils' implementation is fast:

    $ time openssl rand -base64 1000000000 | tr a-z n-za-m >/dev/null

    real    0m1.073s
    user    0m1.327s
    sys     0m0.644s
    $ time openssl rand -base64 1000000000 | rot13 >/dev/null

    real    0m19.225s
    user    0m20.101s
    sys     0m0.747s

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#23
post #9

The method is interesting as a mental exercise and its archaeological interest. If you are a company employee be careful about trying these or any other type of tunneling or deep packet inspection circumvention methods. Some companies mention in their employment contracts these type of circumvention activities, unless explicitly allowed, are a firing offense.

At one job I tunneled out of work to my home PC, and the head security guy found out and made a big stink, and I got fired

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#26
post #15

Earlier quoted context omitted.

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.

You don't even need root. All the important bits can be done in userspace.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#27
post #8

Earlier quoted context omitted.

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

Where does the keyspace come from? rot13 has no keys. Of course you could do rot2 - rot24 and all the other combinations. Is that were the factor 25 comes from? The deep inspection needs to look only at the first couple of bytes of each new a TCP connection. So it's not that disrupting. After 2 bytes you can already skip for a vast fraction of other traffic.

The underlying tool (caesar) will infer the key if you forget to pass it in. It does so without brute forcing.

Applying this to DPI wouldn't be too bad.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#28
post #25

OP should use rot14, it's more secure. /s

double rot13 has an unfortunate meet-in-the-middle weakness but triple rot13 was invented for this very purpose. I hope he makes the upgrade.

For anyone not in on the joke, this is a real crypto concept/weakness/attack https://en.m.wikipedia.org/wiki/Meet-in-the-middle_attack (obviously only a joke with rot13). It's most famously the reason that 3DES is a thing, instead of just double.

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#29
> They permit SSL to some known websites (for https), but the moment I try to create an SSL or SSH connection to an unknown server (eg. to the bastion box), their gateway instantly terminates the TCP connection!

They are clearly already whitelisting connections, but still allow unidentified connections through?! What sort of logic is that?

Re: Circumventing Deep Packet Inspection with Socat and Rot13

#30
post #14

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.

http://www.ranum.com/security/computer_security/editorials/d...

"The Six Dumbest Ideas in Computer Security"

> #1) Default Permit

> #2) Enumerating Badness

Post reply on HN