arma at mit.edu
Mon Mar 26 01:37:54 UTC 2012
On Sun, Mar 25, 2012 at 07:18:44PM -0400, Hooman wrote:
> In our recent work, SkypeMorph , 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).
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?
More information about the tor-dev