commit 15a659481601670a8081bec25e21686beb927138 Author: David Fifield <david@bamsoftware.com> Date: Sat Jun 11 12:26:53 2011 -0700 Remove outdated information from README. --- README | 52 +++++++++++++--------------------------------------- 1 files changed, 13 insertions(+), 39 deletions(-) diff --git a/README b/README index 8597a96..ff12174 100644 --- a/README +++ b/README @@ -5,24 +5,12 @@ Adobe Flash proxy running on another computer. The Flash proxy can be run just by opening a web page in a computer that has Flash Player installed. -This RTMFP version leverages the NAT-punching capabilities of Adobe's -Cirrus server, making it possible for clients behind a NAT to still -get access to Tor. The big operational difference between this version -and the swfcat version is that now the client must maintain a rtmfpcat -running in client mode open in his/her browser. The client's rtmfpcat -talks to the rtmfpcat proxy running on another computer (location uncertain) -via the UDP-based RTMFP to funnel data to a Tor relay/bridge. - There are five main parts. Our terminology for each part is in quotes. 1. The Tor "client," running on someone's localhost. -2. A "connector," which waits for connections from the client's rtmfpcat and +2. A "connector," which waits for connections from the Flash proxy and the Tor client, and joins them together. 3. A Flash "proxy," running in someone's web browser. This piece is - called rtmfpcat (totally ripped off of swfcat) because it is like a - netcat implemented in Flash. The rtmfpcat exists on both the local - and remote ends since it's the easiest way to take advantage of RTMFP. - We could get rid of the client-side rtmfpcat by making the connector - speak RTMFP, but that's too much work for now. + called swfcat because it is like a netcat implemented in Flash. 4. A "facilitator," a pseudo-HTTP server that keeps a list of clients that want a connection, and hands them out to proxies. 5. A Tor "relay," which is just a normal Tor relay except that its host @@ -46,40 +34,34 @@ variable CIRRUS_KEY so it can be found by Makefile. To build, run $ make -Copy the resulting rtmfpcat.swf file to a web server. +Copy the resulting swfcat.swf file to a web server. On the computer that will be the facilitator, run sudo ./crossdomaind.py ./facilitator.py crossdomaind.py needs to be run on any server that will accept connections from a Flash proxy. It serves a chunk of data on port 843. -The facilitator runs on port 9002 by default. Note that this is a different -facilitator script than the swfcat one, since this facilitator needs to -deal with Cirrus client IDs instead of ip:port tuples. +The facilitator runs on port 9002 by default. The client needs to be running a version of Tor that supports the Socks4Proxy configuration. This means version 0.2.2.1-alpha or later--not the current stable release. On the client, run - ./connector.py -This is a modified form of the swfcat connector.py that has different -defaults, equivalent to passing 127.0.0.1:9001 for [LOCAL][:PORT] and -127.0.0.1:3333 [REMOTE][:PORT] to the swfcat connector. - -Also on the client, open up the browser to rtmfpcat.swf. Passing no + ./connector.py 127.0.0.1:9001 127.0.0.1:9002 +Also on the client, open up the browser to swfcat.swf. Passing no arguments should give you good defaults (expects the facilitator running -on Nate's server). rtmfpcat will connect to the Cirrus server to +on Nate's server). swfcat will connect to the Cirrus server to obtain a client ID which it then registers with the facilitator. -In a browser somewhere, open rtmfpcat.swf and pass the "?proxy=true" query -string, telling it to operate in proxy mode. - http://www.example.com/rtmfpcat.swf?proxy=true -This rtmfpcat will also connect to the Cirrus server to obtain a client ID, +In a browser somewhere, open swfcat.swf and pass parameters telling it +which facilitator to use and to operate in proxy mode. + http://www.example.com/swfcat.swf?proxy=true&facilitator=<FACILITATOR_IP>:9002&debug=1 +This swfcat will also connect to the Cirrus server to obtain a client ID, and then it will ping the facilitator to check if there are any registered client IDs. If there is one, it will open a RTMFP connection (coordinated by the Cirrus server) to the client and an additional connection to a -hardcoded Tor relay (David's bridge, nicknamed eRYaZuvY02FpExln). +Tor relay. Back on the client, start Tor with the following configuration: UseBridges 1 @@ -92,7 +74,7 @@ If you see messages like try deleting the files in ~/.tor or /var/lib/tor. You will be able to see byte counts flowing in both browsers displaying -rtmfpcat.swf (client and proxy), and eventually be able to build a circuit. +swfcat.swf (client and proxy), and eventually be able to build a circuit. == Rationale @@ -111,14 +93,6 @@ Clients register with the facilitator by sending an HTTP message: POST / HTTP/1.0\r\n \r\n client=<CIRRUS-CLIENT-ID> - -The <CIRRUS-CLIENT-ID> is returned by Adobe's developer Cirrus server -as soon as the rtfmpcat can connect to it. Each rtmfpcat needs to connect -to a server like this to get one of these client IDs, since the Cirrus -server uses these to coordinate RTMFP connections (including NAT punching). -The need to communicate with a Cirrus server in addition to a facilitator is -one of the major weaknesses of this design. - The Flash proxy also gets a client address over HTTP: GET / HTTP/1.0\r\n \r\n