Rendezvousing at Third Party Storage Services
Emily Stark and Siddhi Soman
Spring 2011
Project Description
In the case that a client inside a censored region has no access to Tor, our project provides a difficult-to-block channel of communication by storing requests and responses in many large general-purpose storage services such as Amazon Web Services and Google Docs. Clients can use this channel to obtain bridge addresses or exchange information needed to set up a higher bandwidth connection. Clients can even use this channel to (very slowly) browse the Web, in the case that all other attempts at connectivity fail.
One of the premises of our project is that clients inside a censored region will usually have access to large, general-purpose services such as Google and Amazon. Even in the event that some of these services are blocked, a client needs access to only one service at any given time to be able to rendezvous with nodes outside the censored region and set up a full connection.
Our project exports a generic put() and get() interface for each storage service. A client in a censored region calls put() to broadcast a request (for example, a request for a bridge address or a HTTP request) and then repeatedly calls get() until it finds a response. Meanwhile, a server outside the censored region repeatedly calls get() until it finds an unserviced request; it services the request and posts the response by calling put(). This generic interface allows clients and trusted nodes to rendezvous for a variety of applications, which we discuss below.
Applications
- Distribute Flash proxies. A different CS294S project uses Flash badges to proxy Tor requests from clients inside the censored region to bridges outside the censored region, thereby enabling full connectivity. The Flash proxies will be many in number but very short-lived, and they must be distributed quickly and frequently to clients in a way that can't be blocked. Our project allows Flash proxies to be distributed via many storage services, so that if a client has access to any one storage service, the client can obtain the address of a Flash proxy and have full Internet access.
- Set up Skype connections. Yet another CS294S project tunnels Tor packets through the Skype overlay network from a Skype client inside the censored region to a Skype node outside the censored region. For this connection to be made, the client and the external node must know each other's Skype user IDs, which they can learn via a third-party storage service.
- Simple web browsing. In the unlikely event that all other attempts at connectivity fail, a client can access censored websites by proxying requests through a third-party storage service. In our tests with AWS, this type of browsing was slow enough to only be useful for simple web pages.
Implementation Details
As previously discussed, each storage service is represented by a get() and put() interface. Each application uses this interface to post and receive requests and responses.
Though it appears at first that almost any service with a public API would be usable for this purpose, in fact the service must provide access control of a certain granularity. The reason for this need is that all clients using the service will share the same credentials. (A client shouldn't have to create an Amazon Web Services account, which requires a credit card number, to rendezvous, nor should all a client's requests be linked to one set of credentials.) Even though all clients share the same credentials, a malicious client should not be able to forge, overwrite, or delete other clients' requests or responses. Though it is not possible to enforce this policy with every API, we have found that it is often possible when the API offers one or more of: version history, an ability to disallow the client from deleting objects, and/or an ability to disallow the client from enumerating objects.
We give two examples of how to protect honest clients from malicious clients using access control policies for different services:
- Amazon Simple Queue Service has fine-grained access control policies. The client credentials allow each client to enqueue (but not dequeue) a message to the connections queue, to create queues, and to enqueue and dequeue all queues other than connections. The client is not allowed to enumerate all queues. To request a connection, the client chooses a random connection ID and enqueues this ID in the connections queue. The client creates two new queues, <conn_id>_request and <conn_id>_response, where it posts its request and checks for a response. A malicious client cannot read or delete other clients' connection IDs from the connections queue because it does not have permissions, and a malicious client cannot read, write, or delete requests or responses without guessing the connection ID in the request and response queue names (because it does not have permission to enumerate all queues).
- Box.net is a file sharing and storage service that offers access control levels such as Viewer, Editor, Uploader, and Owner. Uploaders are only allowed to view the files in a folder and upload new files to the folder (though if a file with the same name exists the file will be overwritten and the previous version saved to the version history). The client credentials have Uploader permissions on a requests folder, and the client uploads a file with its request to this folder. The node outside the censored region that services requests downloads files in the requests folder to process requests, but this node only ever downloads the earliest versions of each request file so a malicious client overwriting requests will have no effect. The node outside the censored region then posts the response to a responses folder where clients have read-only access.