CS294S Research Project in Computer Security

Skype Proxy (IP over Skype)



  1. Description
  2. Background
  3. How it Works
  4. Open questions


Our project tries to answer this question: How can we leverage existing and deployed functionality to route around an adversary, who is trying to prevent a user from communicating with an end-host?

In particular, the two end-hosts that we are interested in are the Tor client (user) and the Tor Onion Router.

We have identified several methods which answers our question. In this page, we look at one approach that uses Skype to circumvent an adversary.



Skype is currently the largest peer-to-peer VoIP application. Skype nodes join the skype overlay network on successful authentication with the centralised Skype Login server. Skype nodes are either "normal" nodes or "super nodes." Super nodes act as relays and help establish connectivity between normal nodes, should there be any issues in direct connectivity.

Though Skype has not publicly disclosed its protocol, there are numerous research papers that infer details through experiments.

How it works

We leverage Skype's large number of supernodes to relay data for us. Skype has a plugin architecture that allows developers to access some of Skype's functionalities. For example, Skype allows an application to transmit datagrams between end-points identified by a Skype login. Skype does most of the heavy lifting like NAT traversal, identifying supernodes that can relay, and routing datagrams through those relays.

The list of functionalities are available on Skype's Developer Website. The feature that we use is called AP2AP.

High Level Overview

The client is unable to access the Tor network directly, as the firewall has blocked access to all Tor Onion Routers (OR). All ORs are also logged in to the Skype network and their login IDs are publicly known and distributed through a reliable directory service (by Emily/Siddhi). The following diagram shows a qualitative overview of the system.

Both the client and Onion Router (OR) run Skype and our Skype plugin, which Tor sees as a SOCKS proxy to reach the OR. When a user detects that direct connections are blocked, she configures Tor to use the SOCKS proxy.

Open questions

How easy/difficult is it to block Skype? Since we rely on Skype, it is important to understand its resilience to blocking. Skype has been known to be difficult to block using just IP addresses. It requires packet inspection. Some techniques are listed on this page: http://www.cs.columbia.edu/~salman/skype/. Note that it blocks Skype completely, and not just the AP2AP interface which we use.

How much bandwidth is available? The Skype documentation notes that relayed traffic is throttled, but does not specify to what rate it is throttled. This needs to be measured.

How to choose new relays? The Skype API does not give control over the choice of supernode relays during datagram transmission. So, if a relay is blocked, we do not know how to force Skype to choose a new supernode relay.

How are new relays chosen? Once applications start transmitting datagrams, Skype changes supernode relays periodically. We do not know how this is done.

Can Skype block this application?

Source code