On Sun, Mar 25, 2012 at 07:18:44PM -0400, Hooman wrote:
In our recent work, SkypeMorph [2], we have tried to use Skype video communications as our target protocol for protocol obfuscation. SkypeMorph functionality is similar to Obfsproxy, but the connection between the bridge and the client looks like a Skype video call (the details of how we do this is discussed in the technical report).
Hi Hooman,
Looks like a great first release. Thanks for sharing it with us!
Can you give us some guesses about next steps for resolving these issues (or explaining why they aren't actually as worrisome as they appear)?
A) It looks like the transport has no notion of adapting to network conditions, i.e. congestion control. So it will basically fall apart on a low-bandwidth or congested network.
B) It sends at a constant rate of 43KB/s in each direction all the time. Even if users are willing to tolerate that, it doesn't scale on the bridge/relay side if there are lots of users. I wonder how feasible a "traffic shaping" approach would be (where the flow rate drops off if there's no underlying traffic), and how much that would screw with your statistics. Which leads to:
C) The packet size and timing distributions only aim to match the first-order properties of Skype. At the same time, DPI vendors have already been in a battle with Skype traffic for a while now. How advanced do you think DPI vendors are at detecting Skype-like traffic, and thus at distinguishing your traffic from real Skype traffic? Similarly, how bad is it that you don't follow through with the TCP side of the Skype handshake?
D) The morphing output is basically identical to the naive shaping. Are you sure you did it right?
--Roger