[tor-dev] SkypeMorph

[Hooman]

On 12-03-25 09:37 PM, Roger Dingledine wrote:
> 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.
True, but as mentioned in section 8.2 of the technical report, this can 
be fixed by considering Skype video calls on different networks, 
depending on the network status. (the way Skype bandwidth usage varies 
with available bandwidth is studied, for example: 
http://www.tlc-networks.polito.it/oldsite/mellia/papers/skype_info08.pdf )
>
> 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:
43KB/s is per connection, so each client gets this bandwidth, while the 
bridge can have multiple connections.

> 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?
The TCP connections are more of control connections and they send a 
small number of messages during the call and we actually have some ideas 
on how to deal with this, like handing the sockets for these connections 
to our software after we fake a call.
>
> D) The morphing output is basically identical to the naive shaping. Are
> you sure you did it right?

So as mentioned in the report, the original traffic morphing does not 
consider timing at all (which makes it less effective against DPIs) and 
it aims at minimizing the overhead, ie the number of padding bytes sent 
on the wire. When we introduced the inter-packet timing feature, it was 
no longer possible to go with the same construction, since packets may 
not be send right away. As a result we tried a different approach for 
traffic morphing: we buffered packets received from Tor, then when it is 
time to send the next packet, we simply estimate the original packet 
size by a sample form the Tor's packet size distribution. I know there 
are other ways this can be done, but in our experiment we didn't observe 
any tangible difference in the outcome.

> --Roger
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev