uproxy-churn
============

[![Build Status](https://travis-ci.org/uProxy/uproxy-churn.svg?branch=master)](https://travis-ci.org/uProxy/uproxy-churn) [![devDependency Status](https://david-dm.org/uProxy/uproxy-churn/dev-status.svg)](https://david-dm.org/uProxy/uproxy-churn#info=devDependencies)

Obfuscated WebRTC data channels.

### Overview

WebRTC supports the creation of peer-to-peer data channels. WebRTC data channels
are secured with
[DTLS](http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Security).
An observer of the network traffic between two connected hosts can trivially see
that DTLS is in use; from this, they may infer that data channels are in use. We
wish to make it difficult for an observer to detect the use of data channels.

This repository builds a Freedom module which affords control over WebRTC data
channels at the network layer. The module, `churn`, provides an interface
similar to `uproxy-lib`'s `uproxypeerconnection`.

`churn` works by configuring WebRTC to pipe its peer-to-peer data through a
local TURN server. This affords us an opportunity to transform the data prior
to sending it over the network; `churn` code on the remote host then restores
the data to its original format prior to delivering it to the remote WebRTC
peer.

Currently, [uTransformers](https://github.com/uProxy/uTransformers) are used to
transform and restore the data being sent over the network. The
[libFTE](https://github.com/uproxy/libfte) transformer, in particular,
affords great control over format of the data across the untrusted network.

This repository builds two sample apps, both Chrome apps.

#### turn

Demonstrating the simplest possible use of the `turn` and `net` modules,
this app spins up a TURN server on port 9997.

The server may be used with standard TURN clients, e.g. the command-line
tools from the `rfc5766-turn-server` suite:

* Install the [rfc5766-turn-server](https://code.google.com/p/rfc5766-turn-server) client utilities (`apt-get install rfc5766-turn-server` on Debian-like systems)
* Open a terminal and execute `turnutils_peer`. This starts a UDP echo server on ports 3480 and 3481.
* Open another terminal and execute `turnutils_uclient -s -u test -w test -e 127.0.0.1 127.0.0.1 -p 9997`

You should see a flurry of activity in the Chrome debugging console. On the
command line, you will soon see a report. The output is not very user-friendly
but the important parts are `tot_send_msgs` and `tot_send_bytes`. With the TURN
server, echo server, and TURN client all running locally, you should not see any
dropped packets. For more options, e.g. to open more channels or send larger
datagrams, see the
[turnutils_uclient documentation](https://code.google.com/p/rfc5766-turn-server/wiki/turnutils_uclient).

#### chat

Demonstrates how the `churn` module may be used to drive a two-way chat client.

The endpoints in use - along with a lot of debugging information - may be
determined by examining the Javascript console; to convince yourself that the
data is indeed obfuscated, examine your system's network traffic with the help
of wireshark.