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.
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?