[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Final Fog Combiner GSoC Report and Fog Status/Description
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev