[tor-commits] [flashproxy/master] Update documentation for combined TCP/RTMFP proxy.

dcf at torproject.org dcf at torproject.org
Sun Jun 12 08:56:31 UTC 2011


commit f6e2fb73a707c34760326fa760406a38f7144c35
Author: David Fifield <david at bamsoftware.com>
Date:   Sun Jun 12 01:40:11 2011 -0700

    Update documentation for combined TCP/RTMFP proxy.
---
 README     |   73 +++++++++++++++++++++++++++++++++++++-----------------------
 design.txt |   19 +++++++++++----
 2 files changed, 59 insertions(+), 33 deletions(-)

diff --git a/README b/README
index ff12174..4b6a2dc 100644
--- a/README
+++ b/README
@@ -16,6 +16,10 @@ There are five main parts. Our terminology for each part is in quotes.
 5. A Tor "relay," which is just a normal Tor relay except that its host
    must also serve a Flash crossdomain policy.
 
+A proxy is capable of connecting to a client in two ways: Using a normal
+TCP connection, or over Adobe RTMFP, which involves a third party but is
+capable of traversing NAT.
+
 == Demonstration page
 
 https://crypto.stanford.edu/flashproxy/
@@ -28,42 +32,56 @@ Download the (free software) Flex SDK.
 	http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK
 Put its bin directory in your PATH. The important executable is mxmlc.
 
-You need a Cirrus developer key from Adobe. Put it in the environment
-variable CIRRUS_KEY so it can be found by Makefile.
+For RTMFP support, you need a Cirrus developer key from Adobe. Put it in
+the environment variable CIRRUS_KEY so it can be found by Makefile.
 	$ export CIRRUS_KEY=XXXXXXXXXXXXXXXXXXXXXXXX-YYYYYYYYYYYY
 
 To build, run
 	$ make
 Copy the resulting swfcat.swf file to a web server.
 
-On the computer that will be the facilitator, run
+=== Connecting
+
+On the Tor relay, 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.
+In general, any computer that a proxy connects to needs to serve a
+crossdomain policy, but the connector and facilitator have it built in.
+
+On the facilitator, run
+	./facilitator.py -r <relay-ip>
 The facilitator runs on port 9002 by default.
 
+In a browser somewhere, open swfcat.swf and pass it a parameters telling it
+which facilitator to use, for example
+	http://www.example.com/swfcat.swf?facilitator=<facilitator-ip>:9002&debug=1
+
+There are two ways in which the client can receive connections: over TCP
+or RTMFP. TCP doesn't send traffic to anyone other than the facilitator
+and the proxy, but it only works if you have a public IP address. RTMFP
+coordinates connections using a server controlled by Adobe, but works
+when the client is behind a NAT.
+
+To connect with TCP, run
+	./connector.py -f <facilitator-ip>
+(If you are running the facilitator locally, be sure to use an external
+IP address, not 127.0.0.1.) The connector informs the facilitator that
+it wants a connection, then listens on 0.0.0.0:9000 and 127.0.0.1:9001.
+The proxy will connect on port 9000 and the local Tor will connect on
+9001.
+
+To connect with RTMFP, run
+	./connector.py 127.0.0.1:9001 127.0.0.1:9002
+and open in a browser
+	http://www.example.com/swfcat.swf?client=1&facilitator=<facilitator-ip>:9002
+In this case, it is swfcat running in client mode that registers with
+the facilitator. The connector acts to join the local swfcat and the
+local Tor client.
+
 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 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). swfcat will connect to the Cirrus server to
-obtain a client ID which it then registers with the facilitator.
-
-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 
-Tor relay.
-
-Back on the client, start Tor with the following configuration:
+Start Tor with the following configuration:
 	UseBridges 1
 	Bridge 127.0.0.1:9001
 	Socks4Proxy 127.0.0.1:9001
@@ -73,8 +91,8 @@ If you see messages like
 	[notice] no known bridge descriptors running yet; stalling
 try deleting the files in ~/.tor or /var/lib/tor.
 
-You will be able to see byte counts flowing in both browsers displaying
-swfcat.swf (client and proxy), and eventually be able to build a circuit.
+You will be able to see byte counts flowing in the browser window, and
+eventually be able to build a circuit.
 
 == Rationale
 
@@ -92,16 +110,15 @@ policy.
 Clients register with the facilitator by sending an HTTP message:
 	POST / HTTP/1.0\r\n
 	\r\n
-	client=<CIRRUS-CLIENT-ID>
+	client=<ip-addr/rtmfp-id>
 The Flash proxy also gets a client address over HTTP:
 	GET / HTTP/1.0\r\n
 	\r\n
 The server sends back address specifications of a client and a relay in
 an HTTP respose.
 	HTTP/1.0 200 OK\r\n
-	Server: BaseHTTP/0.3 Python/2.5.2\r\n
 	\r\n
-	client=<CIRRUS-CLIENT-ID>&relay=9.9.9.9:9001
+	client=<ip-addr/rtmfp-id>&relay=<relay-ip>
 
 == ActionScript programming
 
diff --git a/design.txt b/design.txt
index 27be8ab..2d5ad2b 100644
--- a/design.txt
+++ b/design.txt
@@ -101,13 +101,19 @@ Design of Flash proxies
   On startup, the connector sends a registration message to the
   facilitator, informing the facilitator that it is waiting for a
   connection. The facilitator will later hand this registration to a
-  Flash proxy. The registration message is an HTTP POST request of this
+  Flash proxy. The registration message is an HTTP POST request of the
   form:
 
     POST / HTTP/1.0
 
     client=[<address>]:<port>
 
+  or the form:
+
+    POST / HTTP/1.0
+
+    client=[<rtmfp-id>]:<port>
+
   The facilitator sends a 200 reply if the registration was successful
   and an error status otherwise. If the connector omits the [<address>]
   part, the facilitator will automatically fill it in based on the HTTP
@@ -141,11 +147,14 @@ Design of Flash proxies
 
     client=[<address>:<port>]&relay=<address>:<port>
 
-  If <address>:<port> is missing, it means that there are no client
-  registrations for this proxy.
+  or this:
+
+    client=[<rtmfp-id>]&relay=<address>:<port>
+
+  If the value for the client parameter is empty, it means that there are no
+  client registrations for this proxy.
 
-  The Flash proxy may serve more than one relay–client pair at once. It
-  limits its own bandwidth to 10 KB/s (combined upload/download).
+  The Flash proxy may serve more than one relay–client pair at once.
 
 8. Behavior of the facilitator
 





More information about the tor-commits mailing list