History

Wiki »

Voice over Tor Project - October 2013

Summary

We received a short-term grant from the Tor Project to implement support for a "Voice over Tor" feature in ChatSecure/Gibberbot. Since Tor itself does not support media streaming via UDP, a TCP-based approach is necessary for audio communication. This mostly rules out SIP-based solutions, few of which can work over TCP. In addition, due to the high latency aspect of Tor, and the general interest in high latency as a good thing to protect anonymity, the design goal was to build an asynchronous voice messaging solution, as opposed to a real-time "full duplex" communication system.

Fortunately, voice messaging is quite popular these days in mobile messaging apps such as WhatsApp, Line and WeChat. As part of a standard mobile chat session, a user might send some text, a few emoji icons, high-res "stickers", and embedded photo, and a voice message or two. All of this content is shared and mixed in a single stream of communications.

The goal was to emulate, as much as possible, the features of these mainstream applications, but instead, ensure a "secure by design" approach to the audio communications, employing both end-to-end encryption of the audio content, and full routing over Tor. ChatSecure (formerly known as Gibberbot) is the open-source mobile messaging application this project built upon to achieve these, utilizing the pre-existing support for the XMPP protocol, and proxying communications over Tor via SOCKS.

Goals

  1. Add audio messaging feature to app that works in tandem with XMPP connection proxied over Tor via SOCKS; this includes new user interface components for audio recording, display and playback; audio encoding; transfer of data over OTR Data channel; completion of OTR Data featureset
  2. Audio must be encrypted end-to-end, from sender to receiver, and must route over Tor at all times.
  3. Implement mitigation of usability issues around high latency data transfer of rich media.
  4. Test with popular xmpp services that work well with Tor (Jabber.ccc.de, Dukgo) and our recommended xmpp server types (ejabberd, prosody).
  5. Perform basic audit of implementation via wireshark to prove it is working, and to understand traffic analysis implications (i.e. "does it look like i am sharing files?"); write up report/blog post, as necessary.

Output

Designs Code Public Announcements

Outcomes

1. COMPLETE (in v13 BETA): Add audio messaging feature to app that works in tandem with XMPP connection proxied over Tor via SOCKS; this includes new user interface
components for audio recording, display and playback; audio encoding; transfer of data over OTR Data channel; completion of OTR Data featureset

  • v12 of Gibberbot, now named ChatSecure, has shipped as FINAL with support for a new data sharing channel, provided through the Off-the-Record encryption protocol. See the OTRDATA v1 Specification for more information on how extra fields within the protocol allow for packetized data sharing inside of the encrypted envelope. This also allows for verified data sharing, through the mechanims OTR provides for key verification, such as Socialist Millionaire Protocol.
  • v13 Beta has implemented an audio sharing enhancement, providing a direct menu option for launching an audio voice recorder task (using a third party application "Intent" API), and for sending the recorded output file directly to the person you are currently chatting with over the OTRDATA channel
  • v13 in addition also offers an "accept all" option per chat session to streamline receiving inbound audio messages so that you do not need to approve each message.
  • v13 finally incorporate automatic playback option for incoming audio, using a built-in MediaPlayer feature, that supports variable encoding and qualities of audio

2. COMPLETE (in v12 RELEASE and v13 BETA): Audio must be encrypted end-to-end, from sender to receiver,
and must route over Tor at all times.

  • As stated above, since our v12 final release, we have implemented the OTRDATA function, which encrypts data end-to-end inside of the OTR/XMPP stream, which is then further encrypted while traveling over TLS-over-Tor.

3. COMPLETE/BEST EFFORT: Implement mitigation of usability issues around high latency data
transfer of rich media.

  • Since the communication occurs over XMPP, it can rely upon our already implemented support for message delivery receipts and reliable communications using XMPP Extensions such as XEP-0184 (http://xmpp.org/extensions/xep-0184.html) and Stream Management (http://xmpp.org/extensions/xep-0198.html)
  • The OTRDATA protocol offers some message retry capability, and in general does not require real-time, low latency connections, due its async messaging nature.
  • We have adopted the 3GPP audio format for default audio communications, which offers excellent compression options and low bitrate. This makes audio messaging quite reliable due to small size, and reduces delays in back and forth communication.

4. COMPLETE: Test with popular xmpp services that work well with Tor
(Jabber.ccc.de, Dukgo) and our recommended xmpp server types (ejabberd,
prosody).

  • Testing has been successfully completed with audio messaging between acccounts on Dukgo.com, Google Talk and privately hosted Prosody server (hyper.to/guardianproject.info). The tests were done both over Wifi and 3G connections.
  • Testing with some issues regarding rate-limiting of XMPP messages has been done on Jabber.ccc.de. Rate-limiting is definitely an issue for the OTRDATA support, and it is strange that a Jabber.ccc.de is the only server we have had a problem with so far. We are reaching out to their adminstrators to understand their configuration better.

5. COMPLETE: Perform basic audit of implementation via wireshark to prove it is
working, and to understand traffic analysis implications (i.e. "does it
look like i am sharing files?"); write up report/blog post, as necessary.

  • ChatSecure utilizes Orbot (Tor on Android) for its connection to Tor. Orbot offers a number of real-time displays of traffic (taken from the Tor Control Port) moving through Tor within the application. Utilizing these outputs, it is clear that the voice data is passing through Tor, due to the rapid increase in transfered packets.
  • Additional, a Wireshark analysis was done to ensure that no audio traffic was leaking or somehow not using the TLS/Tor connection. Results of that will be posted shortly.

device-2013-11-01-170739.png (135 KB) n8fr8, 11/01/2013 09:09 pm

device-2013-11-01-170812.png (346 KB) n8fr8, 11/01/2013 09:09 pm

Also available in: PDF HTML TXT