[tor-dev] Final Fog Combiner GSoC Report and Fog Status/Description

quinn jarrell quinnjarr at gmail.com
Tue Aug 19 01:30:41 UTC 2014


Hi all,

This report is going to be a bit longer and more general than usual as
it'll cover a lot more about the current state of Fog and a description of
it. This is my last report for GSoC, but I will probably continue
submitting patches to Fog.

Here's a general description of what I worked on this summer.

Fog provides an easy way to chain pluggable transports together. It allows
users to obfuscate their Tor data in multiple layers by using the output of
one pluggable transport as the input for another. This will hopefully make
pluggable transports much more difficult to block and provide more
anonymity for users.

Fog has two components, a client written in Python and a server written in
Go. It appears to Tor as a normal pluggable transport and acts like one.
But instead of obfuscating the data itself like other pluggable transports,
it proxies the data through other pluggable transports. It then receives
the obfuscated data and passes it onto the next pluggable transport in the
chain and so on. After the last pluggable transport obfuscates the data and
sends it back to Fog, Fog sends it onto the bridge address where the Fog
server is waiting.

The Fog server works similarly, but reverses the order of the pluggable
transports, allowing each pluggable transport to peel off a layer of
obfuscation. When it completely deobfuscates the data after traveling
through the chain in reverse, Fog sends the data onto Tor as if it is a
normal pluggable transport.

The nice part about Fog is that it requires very little if any modification
of existing pluggable transports to create chains. As long as a pluggable
transport talks obeys the PT-Spec[0] and sends its results to a
prespecified server, it can be used. So for instance all the chains:
b64|obfs3|scramblesuit, scramblesuit|fte|bananaphone|obfs3 will work
without any modification of those pluggable transports.

Now the exceptions to this are pluggable transports that send obfuscated
data to different servers on every startup. This mainly includes the flash
proxy and Meek pluggable transports. These can only be used currently at
the end of a chain. The reason being that since they send to different
servers every time, it is not possible to direct them to a SOCKS shim as
they are configured to only talk a specific protocol instead of just TCP.
They rely on receiving some sort of confirmation or direction instead of
acting as dumb obfuscators.

More specifically, this summer I've been working on generalizing a
prototype that David Fifield(dcf1) and Ximin Luo(infinity0) built chaining
together the pluggable transports obfs3 and flashproxy. The main features
I've added to Fog include

Generalizing Fog to use any pluggable transports instead of just obfs3 and
flashproxy
Generalizing Fog to use any number of pluggable transports to obfuscate data
I modified how Tor connects to Fog, it now uses a SOCKS server to recieve
the request from Tor instead of receiving TCP from the first pluggable
transport as it did before.
Added configuration systems to both Fog client and Fog Server to parse a
format similar to the torrc config files.
Added the ability to support multiple chains with one instance of Fog.
The Fog client will only launch one copy of each pluggable transport even
if that pluggable transport is used in multiple chains.

Over the next few weeks outside of GSoC I plan on adding
A system of passing ClientTransportOptions and ServerTransportOptions to
the chain of pluggable transports. (I worked on this the last two weeks but
was not able to submit it for code review before GSoC ended)
Tests for everything! (Some are written but they are currently in code
review, others will follow)
Documentation. This email is just a general description of Fog, I'll be
adding a bunch more documentation about the structure of fog and a guide to
use it.
Attempting to package Fog as a binary similar to Obfsproxy, though I've
heard bad things about Py2Exe.

In the future, Fog may need to
Modify the PT-Spec to force all pluggable transport servers to transmit
metadata about what IP/port the connection came from. This will let the Fog
server use one copy of pluggable transport for multiple chains and fix an
issue with high traffic causing data to be sent back in the wrong order.

And thats about it for me. I'm headed back to UIUC next week but as when I
have free time, I probably will continue contributed patches to Fog and
maybe other parts of the Tor Project.

I've had a great summer working for the Tor Project. Its been an awesome
time developing Fog and I've learned a massive amount. I can't thank
Infinity0 enough for being my main mentor and teaching me a ton about
what's needed to do open source. He's really guided me to be a better coder
and I'm thankful that he was able to put up with my at times messy/lazy
code. I thought I knew something about how to write clean code at the
beginning of summer. Now I know that I knew nothing lol. Seriously,
Infinity0, thanks so much! I would also like to thank dcf for being my
backup mentor and helping with questions about how the Fog server
worked/potential enhancements to it.

You can see the latest version of Fog at [1]

Quinn

[0] https://gitweb.torproject.org/torspec.git/blob/HEAD:/pt-spec.txt
[1] https://github.com/infinity0/fog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140818/52a92fb2/attachment-0001.html>


More information about the tor-dev mailing list