Re: [tor-dev] SkypeMorph
Hooman hmoha...@cs.uwaterloo.ca writes: On 12-03-28 06:57 PM, George Kadianakis wrote: Hooman hmoha...@cs.uwaterloo.ca writes: We called it SkypeMorph since we are still using the morphing matrix. Although, I personally believe we can find a way to minimize the amount of padding while keeping the timing and sizes statistically indistinguishable from that of Skype's, the traffic morphing technique greatly depends on the characteristics of the source protocol (Tor) and it's not easy to guess the timing patterns of user's behind Tor. So if we use traces from web-browsing behind Tor as the input to our software, and our client uses Tor for downloading multimedia content, in this case traffic morphing would not perform very well. Hm, we encountered the same problem too, while working on the morpher pluggable transport. Traffic morphing would not give us satisfying results, and some times it would even result in more overhead than randomly sampling from the probability distribution of the target protocol. I think we identified the issue in trac ticket #5023 [0]. and also wrote a report on it [1]. Another problem of traffic morphing which is not mentioned on that report, is that traffic morphing works by using an oracle which gives you an integer 'i' with (0 'i' = MTU), and then you have to send a packet of size 'i' to the wire. This usually means that you will _never_ send fragmented IP packets, which looks quite sketchy. I don't think there are any non-messy solutions to the above problems, except from realizing that mimicking the packet size probability distribution of a protocol is probably not worth it at the moment (at least against most current real-life adversaries). Especially so when traffic morphing makes your traffic even more distinguishable in other ways (like in the fact that it's not stateful). Interesting. So you also believe sampling from the target distribution is the best solution at the moment? I'm not sure if there is a best solution here; it mostly depends on your threat model. If your adversary can somehow distinguish packet size probability distributions in real-time, you will probably need to use direct sampling or traffic morphing. I would personally stick with direct sampling, for most cases here. By the way, at the same time, the adversary should not be able to launch the attacks mentioned in my previous post, which are much simpler than distinguishing packet size probability distributions in real-time. For less obscure but more realistic adversaries, I think sillier and simpler padding or split-and-join schemes [0] might also be effective. Finally, 6 weeks ago I disabled dream.c in morpher.git [2], because I suspect that the Matrix Market I/O library of NIST [3], that I was using, is not the best piece of software engineering out there. So George how about the issue I brought up about pluggable transports and how we can stop Tor from making circuits while a transport is setting up a connection? https://trac.torproject.org/projects/tor/ticket/5483 It's not envisioned in the current implementation of the pluggable transports, right? You are not able to do this in the current pluggable transports codebase, but we are developing schemes that will allow you to do tricks like this in the future. I will update #5483. [0]: mentioned here: https://trac.torproject.org/projects/tor/raw-attachment/ticket/4679/pluggable-roadmap.pdf ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SkypeMorph
On 12-03-28 06:57 PM, George Kadianakis wrote: Hooman hmoha...@cs.uwaterloo.ca writes: 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. Right. Minimizing padding bytes on the wire is a big reason to like it. 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. Hrm. So that means your traffic morphing algorithm doesn't try to reduce padding bytes? That makes your graph 5 make more sense. But is it really accurate to call it morphing still? It would be great to explore that tradeoff more. We called it SkypeMorph since we are still using the morphing matrix. Although, I personally believe we can find a way to minimize the amount of padding while keeping the timing and sizes statistically indistinguishable from that of Skype's, the traffic morphing technique greatly depends on the characteristics of the source protocol (Tor) and it's not easy to guess the timing patterns of user's behind Tor. So if we use traces from web-browsing behind Tor as the input to our software, and our client uses Tor for downloading multimedia content, in this case traffic morphing would not perform very well. Hm, we encountered the same problem too, while working on the morpher pluggable transport. Traffic morphing would not give us satisfying results, and some times it would even result in more overhead than randomly sampling from the probability distribution of the target protocol. I think we identified the issue in trac ticket #5023 [0]. and also wrote a report on it [1]. Another problem of traffic morphing which is not mentioned on that report, is that traffic morphing works by using an oracle which gives you an integer 'i' with (0 'i' = MTU), and then you have to send a packet of size 'i' to the wire. This usually means that you will _never_ send fragmented IP packets, which looks quite sketchy. I don't think there are any non-messy solutions to the above problems, except from realizing that mimicking the packet size probability distribution of a protocol is probably not worth it at the moment (at least against most current real-life adversaries). Especially so when traffic morphing makes your traffic even more distinguishable in other ways (like in the fact that it's not stateful). Interesting. So you also believe sampling from the target distribution is the best solution at the moment? Finally, 6 weeks ago I disabled dream.c in morpher.git [2], because I suspect that the Matrix Market I/O library of NIST [3], that I was using, is not the best piece of software engineering out there. So George how about the issue I brought up about pluggable transports and how we can stop Tor from making circuits while a transport is setting up a connection? https://trac.torproject.org/projects/tor/ticket/5483 It's not envisioned in the current implementation of the pluggable transports, right? [0]: https://trac.torproject.org/projects/tor/ticket/5023 [1]: https://trac.torproject.org/projects/tor/raw-attachment/ticket/5023/morpher.2.pdf [2]: https://gitorious.org/morpher/morpher/commit/73d30a0b5aad54d2d52b542d45253c0eedac7456 [3]: http://math.nist.gov/MatrixMarket/mmio/c/mmio.c ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SkypeMorph
On Sun, Mar 25, 2012 at 07:18:44PM -0400, Hooman wrote: 2- SkypeMorph and pluggable transports: Although our code can potentially be used as a pluggable transport, there is a minor difficulty with the pluggable transport framework that needs to be addressed before it can host our code. As mentioned above, our code uses Skype network for basic login stuff, so it takes a little bit more time than what Tor expect from a typical transport (like Obfsproxy), so the Tor client gives up building circuits after a while. We are aware of ORControllers tricks to solve the problem, but it does not seem to be the right way to do it and it would be awesome if the pluggable transport were able to tell Tor that it's working on setting up the connection, and that Tor shouldn't give up on it until it says it's ready. I am sure other transports could also benefit from this. I've opened https://trac.torproject.org/projects/tor/ticket/5483 for further discussion on this topic. Thanks, --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] SkypeMorph
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
