[tor-dev] GSoC - Tor pluggable transports project

[Ximin Luo]

On 14/03/14 20:56, quinn jarrell wrote:
> Hi Tor Devs,
> I'm a computer engineering undergrad at University of Illinois Urbana-Champaign. I am interested in working on a GSoC pluggable transports project.
> I mainly code in python or common lisp and have worked with asynchronous programming before (albeit it was a java framework not twisted).
> The two projects I am interested in are the pluggable transports combiner or building the CBR transport plugin.
> 
> I really like the idea of the transport combiner but I have a few questions about how far along the design/implementation is. I noticed that there is a prototype called obfs-flash proxy and am wondering if I would work on extending that to work with other plugins or if I would work on a separate combiner. Is the design set in stone yet or is the spec for it still shifting? And if the spec is still shifting, how should I address that in my GSoC proposal.
> 

The design is about half-way finished, though we haven't started a proper "spec" document yet. You would finish the design, #10061 [1] - basically handle the more complex cases, to generalise obfs-flash to more types of PTs. This won't be a trivial task - for example, note the last two comments by me and asn in that ticket, which will involve some careful thought to address.

I have some rough notes and diagrams in [1] which give a brief description and justification of the design of the combiner-client. (We are favouring option 2, composition.) For the combiner-server, [3] is a similar sort of diagram. You may find that you will need to tweak these designs, to address all the issues that you may run into.

The two immediate next tasks are:

https://trac.torproject.org/projects/tor/ticket/9580 - fairly simple, you could do this as part of your proposal, to show us how your coding skills are
https://trac.torproject.org/projects/tor/ticket/9744 - a bit more complex, partly done for obfs-flash-server already - but I imagine the syntax of the config file would change, as we work our way through #10061.

We should also decide what to call it:

https://trac.torproject.org/projects/tor/ticket/9743

We're favouring either "fog" or "fogproxy", but we haven't made an official decision yet. We have IRC meetings every 2 weeks on Friday at 17:00 UTC, next one is on March 28th. Feel free to come along!

[1] https://trac.torproject.org/projects/tor/ticket/10061
[2] https://github.com/infinity0/tor-notes
[3] https://trac.torproject.org/projects/tor/attachment/ticket/9744/server-superproxy.jpg 

> I also talked with Yawning in IRC who pointed me to the CBR transport plugin/unix like plugins to change data length/obfuscate data/add noise. I love the idea that with the combiner a CBR transport could be easily added to any existing transport but if the combiner has not been built/the spec is still developing, I wonder how useful it would be. Also the CBR plugin does not seem to be enough work for a GSoC project but I could definitely be underestimating the difficulty. 
> 
> I would like to work on either of these projects but I do not know which one would be the more helpful/necessary so i would love to hear your opinions on which would be better to work on.
> 


Both would be good, you can pick. The CBR plugin has no existing development work behind it (only research), which may or may not suit what you want to do. I am confident it will be enough work for a whole GSoC project however. obfs-flash is written in Python and Go, which may help you learn async programming faster.

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140315/2588e323/attachment.sig>