On 12-03-25 09:37 PM, Roger Dingledine wrote:
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 )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.
43KB/s is per connection, so each client gets this bandwidth, while the bridge can have multiple connections.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:
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.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?
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@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev