Re: [tor-talk] Slides about the Tor Project and the Flash Proxy

[David Fifield <david@xxxxxxxxxxxxxxx>]

On Sat, Nov 10, 2012 at 11:23:20PM +0100, Jorge Couchet wrote:
> At the request of David, I'm sending the link to some slides about the Tor
> Project and the Flash Proxy:
> 
> http://www.slideshare.net/uyjco0/tor-project-overview

This is quite an impressive summary of the technology involved. The
blocking of port 25, preventing flashproxy-reg-email from working, is a
real issue. I've started making usability notes here:
https://trac.torproject.org/projects/tor/wiki/FlashProxyUsability

You marked some question in red circles, so I will answer them.

> Page 5, "If I'm only interested in anonymity: is it safer to use Flash
> proxies anyway?"

Flash proxies are not going to give you better anonymity. You are
basically in the same situation as someone having to use a bridge, in
that your first hop is always the same, except that there is
additionally a flash proxy in front of that first hop. Here is a ticket
about the use of dumb proxies (like flash proxies) instead of Tor relays
as bridges:
https://trac.torproject.org/projects/tor/ticket/2764

> Page 6, "The Server Transport Plugin is just a Websocket Transport
> Plugin (i.e. there isn't the need to implement a special Flash Proxy
> Plugin as in the Client computer)? Where is it implemented?"

That is correct. We are using a third-party WebSocket proxy called
websockify: https://github.com/kanaka/websockify. But there is a ticket
to make our own implementation, so it can work as a managed proxy and
provide better metrics.
https://trac.torproject.org/projects/tor/ticket/5575

> Page 7, "Why isn't possible for the FP ask to the client for the Entry
> node? Is for speed up the connection stablishment? Is the FP only
> choosing for Entry nodes from the Tor Bridges?"

Allowing the client to choose the entry relay would require some
meta-protocol like SOCKS to happen inside the flash proxy, which would
also mean that the client has to somehow embed an address in its
communication with the flash proxy, which increases fingerprintability.
Additionally, we don't want to allow a malicious client to connect
someone's browser to an arbitrary address. The flash proxy JavaScript
takes its orders of what relay to use from the facilitator. The
facilitator only hands out Tor relays supporting the websocket
transport.

> Page 10, "How is working it related with the 'Client proxy'
> configuration and with the Tor Server (i.e. in which address and port
> the 'Server Proxy' is listening the outside connection and how is it
> sending the information to the Tor Server)? How knows the 'Client
> Proxy' where to connect to the 'Server Proxy'?"

The client doesn't know the address and port of the server transport
plugin. The flash proxy learns that information from the facilitator,
and the client gets connected to wherever the flash proxy connects.
Remember that the client transport plugin doesn't actually "connect" to
anything; it only receives connections from outside (from flash
proxies), and doesn't control where those connections come from. You
give an address in the Bridge line only because the protocol requires
it. It is a fake address (0.0.1.0:1) and is not used.

David Fifield
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk