Identifying Obfuscated Protocols
There are many vendors who provide proprietary solutions that claim to support identification of even obfuscated protocols, but none reveal what methods they rely on when performing such protocol identification. Open-source solutions for traffic classification and protocol identification haven't yet had any support for obfuscated protocols. The open-source plug "OpenDPI" from ipoque has purposely been stripped of its possibility to identify encrypted or obfuscated protocols and the popular cannot provide accurate detection of any obfuscated protocol. However, recently an open-source tool has become available that can identify practically any protocol, including obfuscated protocols. This tool is the Statistical Protocol Identification (SPID) proof of concept, which I have made publicly available on .
The SPID proof of concept application is not intended to be a traffic classification tool used in production environments, but rather a demonstration of how well statistical methods can be used to identify most protocols. The SPID application can also be used by designers of obfuscated protocols in order to verify the obfuscation strength of the protocol.
How to Improve Obfuscation
As long as a protocol is identifiable, to a third party monitoring the network traffic, it runs the risk of being subjected to discrimination in the form of traffic shaping or even being completely blocked. To guarantee network neutrality, protocols need to implement proper obfuscation of both payload and flow properties. The payload obfuscation can easily be achieved by applying encryption. Even a lightweight crypto such as RC4 would be sufficient, since even basic more computing resources than an ISP can be expected to throw at large volumes of network traffic. The encryption can alternatively be applied by tunneling the data inside some already existing protocol that employs encryption, such as SSH, SSL or IPSec NAT-T. When doing so, it is important that the tunneling protocol implementation does not differ too much from its normal operation. The anonymity network service TOR, which uses a custom TLS implementation to encrypt connections between Onion Routers, have for example realized the need to modify TOR's TLS handshake to mimic that of Firefox+Apache in order to prevent the traffic from being fingerprinted as TOR. Further information on how to build better obfuscated protocols can be found in the "" report.