Voice over Tor?

Voice calls over Tor are supposed to be impossible. It seems this may no longer be the case.

Without being able to do voice over IP (VOIP) conversations over the Tor network, people are prevented from being able to route calls outside of censored networks. People ask us if there is any way they can route voice traffic through Tor to avoid blocks. To our surprise, we tested Skype and found that it can work acceptably over Orbot.

There are two main reasons that it has been held that VOIP will not practically work over the Tor network.

A technical problem with the transport layer that Tor supports.

The network is too slow for the latency demands of a real-time voice conversation.

However, it turns out Skype has some pretty robust signaling capabilities such that it works on a variety of network conditions. Also, in practice the latency is more usable then one would have thought. This is good news for the future of VOIP traffic over the Tor network, and not only over Skype.

Problem 1: Transport Protocol

TCP is the most common transport protocol for the Internet. It guarantees reliable communication and is used for nearly everything you do in an Internet browser. UDP is a more relaxed protocol used for real-time communications because it reduces latency. The cost for this is that UDP is not reliable and will occasionally drop traffic. For this reason, it is useful for real-time applications that benefit from lower latency. While dropping packets is never ideal, in a real-time communications it usually doesn’t significant affect the quality and even then the time it would take to re-transmit lost packets with TCP might preclude the data being relevant to the stream anymore.

The problem here is that Tor only supports TCP for its transport layer. Meanwhile, VOIP applications use UDP. So they’re not supposed to work over Tor and one of the main difficulties for VOIP users to apply strong anonymity to real-time voice communication.

Even if you tunneled UDP traffic through Tor it would be encapsulated in TCP and lose any benefits that UDP provides for real-time traffic. The TCP mechanisms attempt to account for lost packets and hold delivery of future packets until a resend is complete.

If you’re interested in learning more about networking, I would highly recommend Computer Networks by Peterson and Davie. Its takes a practical approach to teaching the technology and avoids strict adherence to the layered model of the Internet. Beyond that, any TCP/IP or Internet technology introductory resource will get you far!

Solution: Here either Tor needs to support UDP or you need a VOIP client that supports TCP. It had been suggested that Skype will fallback to use TCP connections in instances in which the user has UDP traffic blocked. This is not a very uncommon network policy for some Internal networks and reflects Skype’s effort to make their application work in many hostile network conditions (NATs, firewalls, ect.).

Problem 2: Latency

Second, Tor relays and mixes its traffic across multiple nodes which greatly increases latency. People generally have pretty high performance expectations for latency over a two-way phone conversation. Adding even a couple of milliseconds of lag between conversations can be very noticeable to the user. It causes jerks and jumps in the conversation, making it hard to communicate. For this reason, it is likely that widespread routing of voice traffic through Tor is unlikely. However, people already cope with quite a bit of latency using VOIP internationally, and there are very real security and censorship demands that would require VOIP over Tor. In many situations latency will be quite usable. Let’s see how it actually feels over Tor.

Solution:

The solution here is just accepting the latency. The latency is not ideal but in practice, it is still quite usable. As Tor network performance increases (and one-day supports UDP), real-time communications will begin to have better performance.

Skype over Tor

For testing, I used two Nexus One phones running Gingerbread and the latest Skype binary from the Android App Store. Orbot will transparently route traffic through Tor if you use its transproxy features. The transproxy will drop UDP traffic since it can’t be routed through Tor. It is this feature that causes Skype to fallback to TCP and work over Tor.

First, I looked at normal Skype traffic leaving the phone. It uses some TCP connections to contact Microsoft servers and authenticate your account. Once you start a voice chat you will see lots of UDP traffic as expected. However, if you turn on Orbots transproxy you will see Skype being forced to start up a conversation using only TCP.

Here is a Wireshark screenshot of failed UDP connections to Microsoft servers. I did this by letting the UDP traffic through, logging it, and then dropping it before it left my test environment. So you can see the UDP connections going one way to a variety of IP addresses:

We set one of the phones to route through Tor by turning on the transproxy. Then logged into Skype on each phone and placed a call. Skype worked over Tor! We were having a conversation across two IPs from two different ISPs. The latency wasn’t great, but it was surprisingly usable. I’ve included two-packet captures. One should just look like Tor traffic and is a Skype conversation over Tor. The other is an actual log of the dropped UDP packets (I dropped them at an intermediary device rather than using the Transproxy to capture this). In the UDP log set you’ll see a bunch of UDP traffic originating form a single address (the phone) with no return traffic. They UDP traffic was being immediately dropped after the log.

It turns out you can have a workable VOIP chat over Tor if you use Skype. The findings are interesting because they are relevant to the general problem of trying to use real-time communication through the Tor network. It may also be useful for VERY specific and limited threat models that involve censorship bypass in which there is little risk in being caught.

Here’s to hoping for UDP over Tor in the future. Until then, Guardian Project is working on a design for high latency voice communications. The idea is that you could send quick voice messages with the click of a button similar to how you use an old hand-held radio. We’re toying with names like Push to Torlk and Onion Ringer. Stay tuned!

Disclaimer: In my opinion, Skype is not a secure standard for VOIP communication. It uses non-standard closed source encryption and has likely become CALEA compliant upon acquisition by Microsoft. That means that they have infrastructure in place to intercept communications and relay that information to law enforcement agencies around the world. It is unwise to assume that other state and non-state actors would not also have means to access that data.

Post navigation

14 comments for “Voice over Tor?”

A very informative article, I believe that latency should not be a problem in near future, when Internet connection grow even faster. However, Is it possible for TOR to force the connection through TCP to allow us to communicate on skype?, Can it be tweaked some how?.

First, I m very greatfull for your important work, please keep on. As I m a simple, modest user, I would like to ask, weather in your experiment all skype traffic is sent via tor or only the authentication with Mickeysoft?
Thanks again, I admire your project.

All of the traffic was sent via Tor, but at some point it does leave the Tor network and go to the Skype/Microsoft servers. This means the only thing Tor is protecting is against surveillance or blocking of Skype on the mobile network, and not the entire conversation.

Mostly this is useful then for places where Skype might be blocked, or where using Skype specifically might raise a flag.

All in all, we don’t recommend using Skype, and instead recommend that you check out RedPhone or https://OStel.me

We aren’t endorsing Skype. We just found it interesting that it can do voice very well over TCP and over Tor. Most people don’t believe that Voice over Tor can work (or Video over Tor), so it is ironic that Skype of all apps is the easy way to prove you can.

Now – we are actively looking at open-source, verifiabley secure solutions like Mumble-over-Tor or SIP-over-Tor instead, for an actual solution.

I recently did some tests and had a latency of about 1000 – 2000 mS in the TOR-chain and jitter 300-400 ms due work Nagle algorithm of the TOR nodes. So I used the packet queue and had an additional delay of 350 ms (+20%) but decreased jitter to 50 mS. I used own application with GSM audio codec and point-to-point connection with strong encryption. Now I do some tests for using TOR hidden service for acception calls. This is a great anonimity but twice latency (up to 3-4 sec). I hope to get the acceptable result and report on my work soon.

This has been achieved by controlling the StrictNodes selection from within the Torrc file. The existing node selection focuses on ‘fast’ / ‘high bandwidth’ servers with only port 80 and/or 443 access, however I have other custom built examples (currently unpublished), designed for other more specific purposes.

Setting StrictNodes back to 0 will still offer great speed increases and reduced latency, whilst allowing for the additional port access that may be required for your project.

Thank you! Quick TOR is very important for my work. It would be good to select nodes as the minimum latency and ping, and only stable nodes, if possible. My phone makes small traffic but there is very bad jitter of more than 1.5 sec (freezing tunnel) for it. I used the source code of the old and reliable PGPFone designed by Zimmermann in 1997 and adapted them to work through TOR. Now I have an alpha Windows version of TORFone including the source for further testing available on the my project’s site http://torfone.org. Anyone can contact me by project’s email to further enhance the project.