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.
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.
Reading point #4 on a site called "Hacker News" seems rather ironic.
I wonder how you might encourage deeper introspection into software infrastructure security vulnerabilities, both from closed source companies and from obscure open source projects, without "spreading breadcrumbs for the roaches"
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.
It's interesting how the pendulum of ideas swings back and forth over history, similar problems arise and similar solutions to them resurface also. It would be great to see that on some kind go graph or timeline.
> 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?
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 previous job and AFAIK they are there so that a lazy employee (me) doesn't just skip configuring their tools to go through Artifactory out of laziness and introduce a supply chain vulnerability. If "pip install XYZ" just worked out of the box, how likely would it be that all 10k devs in your organization would bother configuring it to avoid PYPI?
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.
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.
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.
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.
You'r right, the rot13 command is a shell wrapper around:
`
exec /usr/bin/caesar 13 "$@"
`
Forcing the key to be 13. You can obviously invoke /usr/bin/caesar with any of the 25 keys.
This is why rolling your own crypto often works in practice if you are a smaller operator: Nobody ****ing expects it, and there's a good chance nobody cares enough to investigate manually what you did or add support to commercial products to handle it.
I once did rot13 on /lib/firmware/* (not just 13 but 0-255), piped it via 'strings' command and find longest word in English corpus (/usr/share/dict/*). I forget what I found but it's trivial to replicate.
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.
