Greetings, A while ago the Tor project rolled out Obfsproxy as a Browser Bundle [1], for users behind firewalls filtering SSL or detecting other characteristics of a Tor connection, to help them access bridges. 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). We also have an open-source proof-of-concept impelmenation of the SkypeMorph available at: [3] Notes: 1- At the moment our code relies on SkypeKit SDK [4] (a paid Skype SDK which you can get for around US$ 5) for Skype functionalities (the README file in the package explains how one can obtain SkypeKit). However, it can be easily ported to Skype public API [5], so users would not have to pay for it. 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. Hooman [1]:https://blog.torproject.org/blog/obfsproxy-next-step-censorship-arms-race [2]:http://cacr.uwaterloo.ca/techreports/2012/cacr2012-08.pdf [3]:http://crysp.uwaterloo.ca/software/ [4]:http://developer.skype.com/public/skypekit [5]:http://developer.skype.com/public-api-reference
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
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
On Mon, Mar 26, 2012 at 03:04:47PM -0400, Hooman wrote:
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 )
Isn't that like saying TCP congestion control can be implemented by sampling capacity and traffic load on a variety of networks, and then hard-coding the TCP window and resend algorithms to suit the network you think you're running on? I'm not worried here so much about whether your flow adapts to network conditions like a real Skype flow would (though I agree that's an issue). I'm worried about whether your flow would fail to back off at all in the face of congestion, leading to a) Skypemorph not getting its packets through because so many of them get dropped, and b) Skypemorph ruining the network it's running on.
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.
Right. But if a bridge wants to handle 10 Skypemorph users, the bridge needs to be sending out 430KB/s all the time. That means volunteer users can't operate these bridges at home (unless they live in Japan, Korea, or Sweden I guess). It also greatly increases the overall traffic cost of running a bridge. For example, during the February weekend when Iran blocked SSL, my obfsproxy bridge was easily handling ~500 users at once. With Skypemorph that's 172mbit/s of duplex traffic?
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.
Ok. What do you think about the "first-order properties" question about size and timing (e.g. I bet real Skype traffic does not draw its packet size and timing independently from the size and timing of the previous packet)? Combined with the fact that DPI vendors have quite a bit of experience targeting Skype traffic in particular, I worry that they've thought about this specific question more than we have.
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. --Roger
On 12-03-28 02:28 AM, Roger Dingledine wrote:
On Mon, Mar 26, 2012 at 03:04:47PM -0400, Hooman wrote:
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 ) Isn't that like saying TCP congestion control can be implemented by sampling capacity and traffic load on a variety of networks, and then hard-coding the TCP window and resend algorithms to suit the network you think you're running on?
I'm not worried here so much about whether your flow adapts to network conditions like a real Skype flow would (though I agree that's an issue). I'm worried about whether your flow would fail to back off at all in the face of congestion, leading to a) Skypemorph not getting its packets through because so many of them get dropped, and b) Skypemorph ruining the network it's running on.
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. Right. But if a bridge wants to handle 10 Skypemorph users, the bridge needs to be sending out 430KB/s all the time. That means volunteer users can't operate these bridges at home (unless they live in Japan, Korea, or Sweden I guess). It also greatly increases the overall traffic cost of running a bridge.
For example, during the February weekend when Iran blocked SSL, my obfsproxy bridge was easily handling ~500 users at once. With Skypemorph that's 172mbit/s of duplex traffic? I will answer the first two questions here: We are going to get this fixed. So as I mentioned, we are going to do what Skype does: We will use different levels of bandwidth for the output of the SkypeMorph depending on network status (we can detect this the same way TCP detects congestions) or the amount of bandwidth the bridge is willing to dedicate to each client. Another way to do this is to limit the bandwidth provided to each client, as the number of clients increases.
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. Ok.
What do you think about the "first-order properties" question about size and timing (e.g. I bet real Skype traffic does not draw its packet size and timing independently from the size and timing of the previous packet)? Combined with the fact that DPI vendors have quite a bit of experience targeting Skype traffic in particular, I worry that they've thought about this specific question more than we have. Yes, we can definitely go beyond first-order statistics. It should be fairly straight forward to do so.
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.
--Roger
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hooman <hmohajer@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). 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. [0]: https://trac.torproject.org/projects/tor/ticket/5023 [1]: https://trac.torproject.org/projects/tor/raw-attachment/ticket/5023/morpher.... [2]: https://gitorious.org/morpher/morpher/commit/73d30a0b5aad54d2d52b542d45253c0... [3]: http://math.nist.gov/MatrixMarket/mmio/c/mmio.c
On 12-03-28 06:57 PM, George Kadianakis wrote:
Hooman <hmohajer@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]: https://gitorious.org/morpher/morpher/commit/73d30a0b5aad54d2d52b542d45253c0... [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
Hooman <hmohajer@cs.uwaterloo.ca> writes:
On 12-03-28 06:57 PM, George Kadianakis wrote:
Hooman <hmohajer@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/pluggabl...
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
participants (3)
-
George Kadianakis -
Hooman -
Roger Dingledine