[tor-dev] Tor Project proposal for GSoC 2015

[David Fifield]

On Mon, Mar 02, 2015 at 02:51:51PM +0100, Juro P. Doi wrote:
> 
> I would like to participate to the GSoC 2015 (my first one) and contribute to the Tor project. I am registered as timide on the OFTC IRC network.
> 
> I am currently student in master of computer science, and working with LibFTE for a school project.
> Actually, fteproxy can be used as a Tor bridge in order to hide a Tor connection. To use this type of transport, one have to know the address of a remote fte proxy server or use an hardcoded one. I would like to improve the use of fteproxy in order that a client could use his own remote server or at the opposite could ask for one. The main idea is that server nodes announce themselves to a distributed service that clients could query.
> I already had some mail exchanges with the maintainer of the FTE tools, who advised me to post my proposal to the mailing list.
>  
> It can be done at two different points:
>   1. into fteproxy so that it's Tor independant and any service that use fteproxy could benefit of it (as Tor)
>   2. into Tor so that all type of bridges could be shared
>  
> Anouncements should be done over multiple protocols an queried with fallback by the clients.
> These methods could be over services known by hardcoded IP/URL or set by the user.
> Types of services could be:
>   1. services like https://gitweb.torproject.org/bridgedb.git
>   2. IRC
>   3. mail
>   etc.
> 
> What do you think about it?

Distributing bridges over different channels is a good idea. But the
hardest part of the problem, it seems to me, is this: how do you prevent
the censor from learning all your bridge addresses simply by pretending
to be a client? For example, if you have an IRC service that provides
bridge addresses, what stops the censor from polling this service
thousands of times, and adding all the addresses to a firewall
blacklist? It is a very interesting problem. If you have any ideas, they
could be very useful.

BridgeDB has some reasonable answers. It makes the bridge addresses
keyed on your source address, so you have to control a lot of source
addresses (IP addresses or email addresses) in order to learn a lot of
bridges. It also divides bridges into different pools, so if you find
some way to exploit the HTTP pool, for example, and learn all the
bridges, you do not automatically learn all the bridges in the email
pool, too. These answers are not perfect, but they are good enough that
BridgeDB works in most places where people need to use bridges.

There's a separate question, which is whether the interaction with
BridgeDB or something like it could be automatic, rather than manual. It
would be very cool if you could get some personal FTE bridges just by
running Tor Browser. But then you have a challenge: how do you do the
automatic step in a way that the censor cannot just easily block it?
(And if you have a bootstrapping step that cannot be easily blocked, why
not use it for *all* your communication, not just bootstrapping?)

David Fifield