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