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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
