Simple Protocol Obfuscator (protoobfs) concept

Post date: Dec 13, 2012 6:36:15 PM

Protocol Obfuscator (protoobfs)

TL;DR - Name says it all, easily modify (obfuscate) network traffic. So that actual communication protocol isn't identifiable even with deep packet inspection.

1. Abstract

After reading many articles about deep packet inspection and different methods used to block network traffic. I thought that biggest problem with current networking protocols is standardization. Due standardization protocols are easy to identify and block. I kept wondering why there isn't easy way to tweak protocol so that it would allow users to escape almost any deep packet inspection?

My suggestion to solving this problem is Protocol Obfucator layer, which is described in this blog post. It allows modifying any network protocol and hiding internal communication protocol and pattern by using customizable protocol-tweak-modules. Therefore each web-site or any other TCP service can easily use different non-standard protocol which is very easy to modify if required.

If attacker is monitoring the traffic for extended period. It naturally becomes clear to them it's obfuscated traffic. So this is not perfect solution, but the point of this project is to evade simple automated detection and banning.

2. Goals

Here are my initial design goals for this protoobfs project:

1. There must not be any identifiable standardized protocol handshake or port. Without this design goal, project would be totally useless.

2. System must be able to fully modify network traffic to further obfuscated data and protocol being transported inside connection. Traffic can be modified to look like any other traffic by altering protocol timings, messaging patterns by adding traffic, compressing, expanding, encoding and or encrypting existing traffic using programmable module. Connection multiplexing can be preferable and might be implemented after first test versions. So multiple TCP streams would run over one semi persistent tunneling tcp connection.

3. Easy modular design, which uses non-compiled text obfuscator to describe obfuscation mode. Like pure .py file for API.

3. Non-Goals

Because there are counltess tools which provide following services, following things aren't goals for this project.

1. Anonymizing traffic

2. Encrypting traffic

3. Provide strong peer authentication

As you might have noticed, any other protocol can be used over protoobfs layer, like SSL/TLS, HTTPS or SSH, or even obfsproxy itself, you just name it.

4. Proof of concept project

Projects initial proof of concept must be as simple as possible. Therefore I suggest using Python 3.3. and importing obfuscator module. Application is designed to work as tcp-proxy, just like ssh forwarding or stunnel SSL/TLS proxying, Tor Onion layer and many other proxy apps do.

5. Basic Design

There will be two operation modes for proxy app, the client and server mode. Server will be listening for TCP-connections and client will initiate TCP-connections. Both modules are configured using structured plain text configuration file, like props file and importable protoobfs-module. PoC implementation probably won't support using multiple obfuscation plugins simultaneously, but this is feature which could be added later. So when proxy is started on server end, and on client end(s). Depending from plug-in module and state of project, multiplexing constantly connected connection might be used, there could be idle-time out or simple direct connection/connection mode can be used for initial PoC project. All data for that TCP-stream in and out will pass through ProtoObfs-module and get's obfuscated.

6. ProtoObfs plug-in module design

This is most important part of this project, all other parts are trivial. As mentioned in suggested project tools, Python 3.3. would be preferred with importable modules. Why? Because it's ultimately versatile and simple scripting langyage tool. Absolutely anything can be implemented inside small text file module. All we need is API / standardized Python interface for handling data. Because Python doesn't set almost any programming restrictions, anything can be archived. Like simulated fake traffic between actual payload data traffic etc. All original protocol timings can be modified and obfuscated etc.

7. ProtoObfs Interface

interface ProtoObfs:

"This is ProtoObfs data obfuscator interface"

def reset(mode):

"Reset state, called when connection is established"

def sendData(data):

"Obfuscated data and send it to remote host"

def readData():

"Read data from remote host and deobfuscate it"

I'm very aware this is extremely crude sample, but it's already more than enough for base64 test vector implementation. Of course module can maintain complex internal state etc. But main goal is to avoid having anything in basic design and implementation that might immediately reveal that ProtoObfs is being used.

8. Possible proof of concept sample implementations

Very basic sample modules which could be delivered inside standard packet and repositories could be: plain base64 (also as test vector), http, imap, xmpp. With these standard modules any other traffic could be easily encapsulated within valid looking http, imap or xmpp connections. HTTP module could use HTTP/1.1 keep-alive, post and get requests. Which looks to be normal traffic with some browser and server. Same will do with imap and xmpp.

9. What if ProtoObfs traffic gets blocked?

That's the beauty of this project. If you're using module from sample implementations, you just open up the module source code. Change something, which is being blocked and send new version to service provider, or to your users if you're service provider. Protocol isn't same anymore, and now it can pass without getting blocked. Of course in many cases you might also need to change IP-address and maybe the port number. But basic concept is that if something gets blocked (due protocol being used), it's extremely easy to modify the signature of the protocol. Naturally another option would be trying to modify very rigid standardized protocols, like making new version of HTTPS, TLS or SSH, which would require serious coder and some time. Naturally new obfuscator module can be made available to users by using any service (email, web site, chat, etc.) capable of passing pure text files. (The module's python source code)

10. Last words

If you're not familiar with programming, power of this obfuscation might not be clear to you. Using that importable obfuscation module means that basically anyone can create new non-blocked protocols. Also compression, encryption, encodings, timings, handshakes, packet / message sizes and timings can be easily and heavily modified.

Which protocol uses handshake like:

Client: "TXVsZGVyOiBTb3VuZHMgbGlrZSB5b3Uga25vdyBhIGxpdHRsZSBzb21ldGhpbmcgYWJvdXQgdGhlIHN1YmplY3QuCg=="

Server: "U2N1bGx5OiBJIGRpZCBhcyBhIGtpZCwgYnV0IHRoZW4gSSBncmV3IHVwIGFuZCBiZWNhbWUgYSBzY2llbnRpc3QuCg=="

Any bytes sent at the start of connection can be used to modify rest of connection. Therefore using static handshake strings isn't optimal.

11. Feedback, thoughts, contacting me

If you know existing project, which meets similar goals, I'm very interested to hear about it! If there isn't one, I really would like to hear your feedback about this idea.

But there is already obfsproxy. That's true, setting it up requires much more than Python and text file plugin. Also super simple UI could be written for client users. Obfsproxy is much more complex and complete solution. I'm looking for simple and easy to use solution which would allow super easy protocol customization. There has been discussion about obfsproxy plug-in which would make traffic look like Skype traffic.

Flashproxy is interesting project, but it doesn't cover same aspects as protoobfs would.

See other Tor pluggable transports.

See my site: www.sami-lehtinen.net for contact information.

KW: obfucate, obfuscator, protocol, proxy, proxies, ssh, tor, obfsproxy, hiding, obfuscating, protocols, deep packet inspection, freedom of speech, networking, network, firewall, blocking, block, reject, blocked, tweak, tweakable, modifiable, circumvent, circumventing, DPI, full packet inspection, evade, evasion, avoiding, getting, through.