Real Time Traffic Over Tor
Shashwat Chaudhary 2015091 Nikhil Hassija 2015065
BTP report submitted in partial fulfillment of the requirements for the Degree of B.Tech. in Computer Science and Engineering on April 26, 2019
BTP Track: Research Track
BTP Advisor Dr. Sambuddho Chakravarty
Indraprastha Institute of Information Technology New Delhi Student’s Declaration
I hereby declare that the work presented in the report titled “Real Time Traffic Over Tor” submitted by us for the partial fulfillment of the requirements for the degree of B.Tech. in Com- puter Science and Engineering at Indraprastha Institute of Information Technology, Delhi, is an authentic record of our work carried out under guidance of Dr. Sambuddho Chakravarty. Due acknowledgements have been given in the report to all material used. This work has not been submitted anywhere else for the reward of any other degree.
......
Shashwat Chaudhary Nikhil Hassija
Certificate
This is to certify that the above statement made by the candidates is correct to the best of my knowledge.
......
Dr. Sambuddho Chakravarty Place & Date:
2 Abstract
Anonymous censorship resistant communication systems are primarily designed keeping in mind semi real-time traffic such as web browsing. One such system, Tor [1], has gained prominence as the de-facto anonymity preserving censorship resistant system and often used by journalists and whistle-blowers globally. It is however believed that proxy based systems like Tor, that reroute traffic via circuitous paths, potentially incur unwanted latency for real-time applications like VoIP. Moreover, Tor supports only TCP at the transport layer, believed to make it even difficult to send real time data (which depends on UDP). All the existing literature builds on this belief and have proposed various architectures built specifically for anonymous VoIP. However, no one has extensively and empirically quantified the above claims. Hence, in this project we try to explore the performance of VoIP (measuring the PESQ and one way delay) when sent over Tor with various controlled and Internet experiments. The results of these extensive experiments (about 1 million VoIP calls over the Internet) reveal contradictory results in comparison to the existing literature. These results show that anonymous VoIP calling is indeed possible on Tor with more than 80% calls above the PESQ of 3 (considered as good). Acknowledgments
First of all, we would like to thank our B.Tech. project advisor Dr. Sambuddho Chakravarty for providing guidance and direction. We would also like to thank Piyush Sharma, for solving any issues we faced at any point during the project, and guiding us in general regarding what we should be doing. We would also like to thank Falak Wani, for working alongside us throughout the project, and mentoring us about concepts we were not familiar with, and familiarizing us with the code he wrote before we started working on the project.
Work Distribution
• Shashwat Chaudhary - Experiments involving pjsua, freeswitch and openvpn
• Nikhil Hassija - Experiments involving Mumble
i Contents
1 Introduction 1
2 Related Work 2
3 Experimental Setup 3 3.1 SIP Calling ...... 3 3.2 Mumble Calling ...... 3 3.3 SIP Calling Over Tor (V-Tor) ...... 3 3.4 Mumble Calling Over Tor (M-Tor) ...... 4
4 Experiments 5 4.1 Controlled Environment Experiments ...... 5 4.1.1 Maximum Parallel Calls ...... 5 4.1.2 Single call quality in presence of crosstraffic ...... 5 4.2 Real Tor Experiments ...... 5
5 Experimental Results : VPN over Tor 6 5.1 Crosstraffic ...... 6 5.2 Public Tor Network Experiments ...... 6
6 Experimental Results : Mumble over Tor 7 6.1 Public Tor Network Experiments ...... 7
7 Additional Experiments 8 7.1 Skype and Telegram over Tor ...... 8 7.2 Impact of codecs ...... 8 7.3 Impact of wireless medium ...... 9
8 Inferences 10 8.1 Voice quality on Tor ...... 10 8.2 Why we get good quality ...... 10
ii Chapter 1
Introduction
The problem of anonymity and privacy on the internet is a widely discussed one, and various applications exist which provide us anonymity on the internet while incurring tolerable latency overhead, leading to satisfactory web browsing experience. Tor is one such system. The basic principle behind Tor is routing the user’s data through multiple (usually 3) intermediate nodes, called relays, so as to conceal the identity of the sender and/or receiver of data [1]. However, at the same time, anonymous calling on the internet remains a largely unsolved prob- lem. While there are a lot of proposals and prototypes for providing anonymous calls, these prototypes are either completely not deployable, or unmaintained and without any users. See- ing how anonymity network completely rely on their large anonymity set (number of users) to provide anonymity to their users, it is imperative that any anonymous voice calling service have sufficient number of users. Hence, instead of proposing another new architecture, we decided to analyze if it’s possible to leverage Tor’s preexisting infrastructure and users to facilitate anonymous calling over the internet. However, all the literature was dismissive of Tor’s potential to provide anonymous calling. The overall verdict was that the latency of Tor is low enough for semi real-time activities like web browsing, but not for real-time traffic like voice calls. Because of this, our work’s primary goal was to isolate the causes of this poor voice calling performance on Tor. We started by performing initial measurements in a controlled setup. We set up a private Tor network in our lab, and ran some experiments. We found out that in a controlled environment, Tor is quite conducive to voice calls. We then proceeded to repeat the experiments on the real Tor network, anticipating that the calls will perform poorly. However, contradictory to all the previous literature on the topic, we found that Tor was able to support voice calls with good quality in a majority of the cases. We felt that literature in the area was lacking and full of inconsistencies, and felt that there was a need to fill the gaps. hence, we launched a comprehensive measurement campaign to verify if voice calling over Tor is possible, and to isolate what characteristics of Tor permit these voice calls. We found that in more than 80% of cases, voice calls through Tor had acceptable quality.
1 Chapter 2
Related Work
The earliest work on anonymous calling was by Denezis et. al. [7]. They proposed a relaying based system to obscure the identity of the caller, not very different from relaying in Tor. The first comprehensive evaluation of voice calling on Tor was done by Rizal et. al. in his PhD thesis. He observed that while the one way delay of calls on Tor was < 160ms, the call quality was poor because of high packet loss and jitter. [4] Around the same time, Van Gegels wrote TorFone [5], a software that allows users to avail the facility of both side anonymous calling by routing calls through the Tor network. However, TorFone calls have delay upto 4-5 seconds, which is prohibitive for voice calling. The software is only available for windows XP and isn’t actively maintained. In 2015, Herd architecture for anonymous calling was proposed. They stated that Tor’s rount trip delay was around 2-4 sec (one way delay 1-2 sec). Ting, in the same year, reported Tor RTT as strictly being under 1 sec, i.e. one way delay <500ms. More recently, Heuser et al. [6]. analyzed performance of Mumble over Tor and reported 777ms of average delay, with both communication parties being anonymous. They also reported very low PESQ score, indicating bad call quality. Our delay measurements indicate acceptable delay, and good call quality.
Figure 2.1: Inconsistency in delays reported on Tor
2 Chapter 3
Experimental Setup
Our experiments involved two different setups one using SIP calling and other using Mumble. We went with these two setups as they had been used extensively in all the previous studies conducted.
3.1 SIP Calling
Session Initiation Protocol (SIP) is the most widely used protocol for internet telephony. To be able to call over the internet we need a caller (SIP Client) and routing service (SIP Server) that can handle incoming and outgoing calls. For our experiments we use FreeSwitch [8] as our SIP server and PJSIP [10] as our SIP Client. Both of the tools are Open Source softwares being maintained regularly. Normally, freeswitch would connect two clients (caller and callee) and let them communicate with each other directly. However, to eliminate network overheads of connecting to callee in some cases we emulate the second client (callee) on the server side and play back an audio file to the caller.
3.2 Mumble Calling
Mumble is VoIP application designed for gamers. By its design, Mumble can’t support tradi- tional voice over internet calling as VoIP requires some signaling to setup the call. Since we have no such provisions here and only support for channels - where any number of users can join - we emulate calls by having only two users in a separate channel specifically designated for calling. For our experimental setup we are using the official binaries for Mumble server and nodejs-mumble for our Mumble client. Mumble Server has no feature for playing a file when a user connects, thus in cases when we want to eliminate callee delays we run both server and callee on same system.
3.3 SIP Calling Over Tor (V-Tor)
SIP calling depends on User Datagram Protocol (UDP) at transport layer and Tor has been known to support only Transmission Control Protocol (TCP). Therefore, to be able to send SIP’s UDP packets over Tor we’d need to encapsulate them in TCP packets. This encapsulation isn’t a straightforward task, so we’d need a middle-ware to
3 CALLER TOR RELAYS VPN SERVER SIP SERVER CALLEE
S V T T T S V T T T S V T T S V T S V S S
S SIP Headers + Voice Data V OpenVPN Headers T TOR Headers
Figure 3.1: This figure describes the VPN based setup for anonymous voice calling. The caller establishes a VPN tunnel through Tor, so that all the UDP VoIP traffic traverses the Tor network. On reaching the VPN server, the traffic is sent to the SIP server, which initiates a voice call to the callee. facilitate this and we use OpenVPN for this very purpose. By running OpenVPN via Tor and sending SIP packets through OpenVPN we are able to send our SIP data through Tor.
3.4 Mumble Calling Over Tor (M-Tor)
Mumble supports both in UDP and TCP at trasnport. We can force mumble client to send all its data through TCP. Because of this TCP support and support for SOCKS proxies, Mumble works with Tor out of the box.
CALLER TOR RELAYS MUMBLE SERVER CALLEE
M T T T M T T T M T T M T M M
M MUMBLE VOICE DATA T TOR Headers
Figure 3.2: This figure describes the setup for mumble over Tor. The setup is straight- forward, as the caller configures the mumble client to work in TCP mode. Thereafter, mumble’s traffic is sent over Tor eventually reaching the mumble server, which handles the call procedure between the caller and callee.
4 Chapter 4
Experiments
4.1 Controlled Environment Experiments
4.1.1 Maximum Parallel Calls
We collected data on how many calls can a network with N Mbits/s bottleneck bandwidth support without degrading quality in the following three scenarios - (i) UDP call, (ii) TCP tunneled call and (iii) TCP tunneled call over Tor.
4.1.2 Single call quality in presence of crosstraffic
To further mimic the scenario on the real Tor network, we place calls in the presence of other traffic. We generated traffic by downloading a large file using wget over the same links that the call is using. We varied the number of parallel downloads and compared the impact on call quality.
4.2 Real Tor Experiments
On real Tor, we performed the following three experiments.
1. Voice call from caller to server via Tor.
2. Voice call from caller to callee, with caller identity being anonymised via Tor, while server to callee connection is not anonymised.
3. Voice call from caller to callee, with both ends anonymised via Tor.
We performed each of the above experiment for 2-hop Tor circuits and 3-hop Tor circuits, giving us a total of 6 distinct set of experiments. For each of these experiments, we varied caller and callee location across 7 different countries, and the server location across three different continents (one location each in North America, Europe and Asia). For each such experiment, we performed 1000 calls, and measured the PESQ score, delay, and available bandwidth. We also measured the effect that the medium at the user’s end has on call quality. For that, we performed calls over WiFi and 4G networks, with varying signal strengths. We also tested some additional popular apps like Skype and Telegram.
5 Chapter 5
Experimental Results : VPN over Tor
5.1 Crosstraffic
We observe that as long as the available bandwidth per TCP stream remains more than 84kb/s, the calls are successful, while if it falls below that number, the calls fail completely. When there is 84kb/s and some small surplus bandwidth available, then the call quality is excellent, otherwise it ranges from mediocre to bad as we get closer to exactly 84kb/s.
Parallel Downloads Link B/W B/W per stream Call bitrate PESQ Score
80 10 Mbit/s 125Kbit/s 84 Kbit/s 4.2 100 10 Mbit/s 100Kbit/s 84 Kbit/s 3.4 >110 10 Mbit/s <90Kbit/s 84 Kbit/s <2.3
5.2 Public Tor Network Experiments
1 . 0 1 . 0 2 h o p V - T o r 2 h o p V - T o r 1 . 0 3 h o p V - T o r 3 h o p V - T o r 0 . 8 0 . 8 2 - h o p V - T o r 0 . 8 3 - h o p V - T o r 0 . 6 0 . 6
F F 0 . 6 D D C C 0 . 4 0 . 4 F D
C 0 . 4
0 . 2 0 . 2 0 . 2 0 . 0 0 . 0 0 . 0 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 P E S Q P E S Q 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 P E S Q (a) One side anonymity client- (b) One side anonymity client- (c) Both side anonymity server server-client
Figure 5.1: V-Tor Results
6 Chapter 6
Experimental Results : Mumble over Tor
6.1 Public Tor Network Experiments
We have done close to half a million calls via mumble
1 . 0 1 . 0 2 h o p M - T o r 2 h o p M - T o r 1 . 0 3 h o p M - T o r 3 h o p M - T o r 2 h o p M - T o r 0 . 8 0 . 8 3 h o p M - T o r 0 . 8
0 . 6 0 . 6 F F
D D 0 . 6 C C F
0 . 4 0 . 4 D C 0 . 4
0 . 2 0 . 2 0 . 2
0 . 0 0 . 0 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 0 . 0 P E S Q P E S Q 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 P E S Q (a) One side anonymity client- (b) One side anonymity client- (c) Both side anonymity server server-client
Figure 6.1: M-Tor Results
7 Chapter 7
Additional Experiments
7.1 Skype and Telegram over Tor
1 . 0 S k y p e T e l e g r a m
0 . 8
0 . 6 F D
C 0 . 4
0 . 2
0 . 0
0 . 5 1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 P E S Q
Figure 7.1: This figure shows the PESQ score of 1000 calls done over Skype and Telegram as a CDF.
7.2 Impact of codecs
1 . 0 G S M 0 . 8 S P E E X G 7 1 1
0 . 6 F D
C 0 . 4
0 . 2
0 . 0
1 . 0 1 . 5 2 . 0 2 . 5 3 . 0 3 . 5 4 . 0 4 . 5 5 . 0 P E S Q
Figure 7.2: This figure shows the PESQ score of 1000 calls done with pjsip and openvpn when using different codecs.
8 7.3 Impact of wireless medium
M - T o r V - T o r 4 . 0
3 . 5
3 . 0
2 . 5 Q
S 2 . 0 E P 1 . 5
1 . 0
0 . 5
0 . 0 3 0 4 0 5 0 6 0 7 0 8 0 R S S I ( - d B m )
Figure 7.3: Average PESQ score for 1000 calls over wifi, with strong signal strength and poor signal strength.
9 Chapter 8
Inferences
8.1 Voice quality on Tor
According to ITU, the two requirements for good call quality are >3 PESQ score, and <400 msec one way delay. We have observed in our experiments that for caller anonymity, Tor introduces a latency of <400 msec in more than 90% of the cases. Furthermore, we saw that the calls have >3 PESQ score in more than 90% of cases too. Around 95% of calls satisfy the requirement of both low latency and high call quality.
8.2 Why we get good quality
We know that voice calls by nature have a different traffic pattern than regular TCP traffic. While TCP attempts to transfer data at best possible rate, the calls have a fixed bitrate. For example, the G.711 codec has 84kbit/s bitrate. We have observed in our controlled experiments that if the bandwidth available to the call drops below 84kbit/s, then the call fails completely. Any excess bandwidth available beyond th 84kbit/s is not utilised. We note that the bandwidth available to the call should be more than the codec bitrate for voice calls to function. While the minimum bandwidth requirement is a necessary condition, it’s not a sufficient one. On Tor, virtually all circuits are able to provide the bandwidth that was needed by the call. At the same time, we found that 10% of calls had bad quality. Further investigation lead us to a second condition for good quality voice calls - the required bandwidth needs to be satisfied continuously. Whenever the bandwidth of the call drops below the bitrate, there is noticeable jitter in the audio received at that point of time. Our controlled experiments indicate that having a surplus of bandwidth beyond what is needed by the calls helps reduce the odds of the bandwidth dropping below the bitrate at any point of time. This can be explained by the fact that if surplus bandwidth is available, then the chances of packet loss are reduced. Since packet loss results in TCP reducing it’s congestion window size and hence the bandwidth, packet drops are highly detrimental to a call’s quality. In case of Tor, the interactions between various TCP streams become much more complicated than what we could introduce in our controlled setup. To validate our reasoning, we plotted the score of call against the available bandwidth in Tor for that circuit. We notice that for bandwidth < 400kbps, around 50% calls are acceptable. The percentage of
10 (a) PESQ > 3 (b) PESQ > 4
Figure 8.1: Percentage of calls satisfying high PESQ criteria V/S available bandwidth acceptable calls keeps increasing after that, until it saturates and further increase in bandwidth has no effect. In case we’re measuring calls with PESQ > 3, then the saturation occurs just before 2mbits/sec, while for PESQ > 4, it occurs slightly after 2mbits/sec. However, beyond that, it varies randomly, indicating no correlation in bandwidth and probability of getting PESQ > 4 after around 2mbit/sec. We observe a similar trend in terms of one way delay as well. The percentage of calls with one way delay < 400 keeps increasing till around 2mbits/sec marks, after which it saturates. The percentage of calls with one way delay < 150 keeps increasing till more than 5mbit/sec, after which that also saturates. Hence, while the improvements in PESQ score stop after 2mbit/sec, the delay keeps decreasing till 5mbit/sec. Beyond that, faster circuits make no difference to calling experience. This is in accordance with what we observed in controlled setup, i.e., surplus bandwidth beyond the required bitrate gives us better calls.
(a) One Way Delay < 400 (b) One Way Delay < 150
Figure 8.2: Percentage of calls satisfying low delay criteria V/S available bandwidth
11 Bibliography
[1] Dingledine, R., Mathewson, N., and Syverson, P. Tor: The second-generation onion router. In Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13 (Berkeley, CA, USA, 2004), SSYM’04, USENIX Association, pp. 21–21. @techreportdingledine2004tor, title=Tor: The second-generation onion router, au- thor=Dingledine, Roger and Mathewson, Nick and Syverson, Paul, year=2004, institu- tion=Naval Research Lab Washington DC
[2] The Tor Project, Inc. Tor Metrics, 2018
[3] Reardon, J., and Goldberg, I. Improving tor using a tcp-over-dtls tunnel. In Proceed- ings of the 18th Conference on USENIX Security Symposium (Berkeley, CA, USA, 2009), SSYM’09, USENIX Association, pp. 119–134.
[4] Rizal, Maimun A Study of VoIP performance in anonymous network-The onion routing (Tor) In PhD Thesis Nieders¨achsischeStaats-und Universit¨atsbibliothekG¨ottingen
[5] Gegel, V. Torfone, 2012.
[6] Heuser S., Reaves B., Pendyala P.K., Carter H., Dmitrienko A., Enck W., Kiyavash N., Sadeghi A., and Traynor P. Phonion: Practical Protection of Metadata in Telephony Networks In PoPETs (2017) pp. 170–187
[7] Danezis, George and Diaz, Claudia and Troncoso, Carmela and Laurie, Ben Drac : An Architecture for Anonymous Low-Volume Communications In International Symposium on Privacy Enhancing Technologies Symposium 2010 pp. 202–219
[8] Minessale, A. Freeswitch, 2016.
[9] Yonan, J. Openvpn - open source vpn, 2018.
[10] PJSIP https://www.pjsip.org/
[11] Rix, A. W., Beerends, J. G., Hollier, M. P., and Hekstra, A. P. Perceptual evaluation of speech quality (pesq)-a new method for speech quality assessment of telephone networks and codecs. In 2001 IEEE International Conference on Acoustics, Speech, and Signal Processing. Proceedings (Cat. No.01CH37221) (2001), vol. 2, pp. 749–752 vol.2.
12