[tor-commits] [flashproxy/master] Move design.txt to doc.

dcf at torproject.org dcf at torproject.org
Wed Jul 4 13:10:14 UTC 2012


commit 210d5b2e98e3b6deff480310cd7e424c962fd928
Author: David Fifield <david at bamsoftware.com>
Date:   Wed Jul 4 06:09:13 2012 -0700

    Move design.txt to doc.
---
 design.txt     |  157 --------------------------------------------------------
 doc/design.txt |  157 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 157 insertions(+), 157 deletions(-)

diff --git a/design.txt b/design.txt
deleted file mode 100644
index ecee83c..0000000
--- a/design.txt
+++ /dev/null
@@ -1,157 +0,0 @@
-Design of flash proxies
-
-0. Problem statement
-
-  Provide access to the Tor network for users behind a restrictive
-  firewall that blocks direct access to all Tor relays and bridges.
-
-1. Overview and background
-
-  We assume the existence of an adversary powerful enough to enumerate
-  and block all public and non-public (bridge) relays. For users facing
-  such an adversary, we assume there exists a subset of reachable hosts
-  that themselves can reach the Tor network. We call this subset the
-  unrestricted Internet.
-
-  A browser-based proxy (flash proxy), running in a web page in the
-  unrestricted Internet, proxies connections between the restricted
-  Internet and the Tor network. These proxies are expected to be
-  temporary and short-lived, but their number will be great enough that
-  they can't all be blocked effectively.
-
-  The implementation of a browser-based proxy using Adobe Flash or other
-  networking technologies is complicated by restrictions that prevent it
-  being a straightforward proxy. Chief among these is the lack of
-  listening sockets. Flash and, for example, WebSockets, can only
-  initiate outgoing connections, not receive incoming ones. The flash
-  proxy can only connect to external hosts by connecting directly to
-  them. The other significant restriction is that the proxy cannot
-  connect to just any destination. A third, but less important,
-  restriction is that browser-based networking does not provide
-  low-level socket access such as control of source address.
-
-2. Components
-
-  Conceptually, each flash proxy is nothing more than a simple proxy,
-  which accepts connections from a client and forwards data to a server.
-  But because of the limited networking facilities available to an
-  in-browser application, several other pieces are needed.
-
-  1. Tor client: Is just ordinary Tor with a special configuration to
-     allow it to connect through a flash proxy. It advertises its need
-     for a connection the the facilitator, and communicates with the
-     flash proxy through the connector.
-  2. Connector: Runs on the same computer as the Tor client. It opens
-     one socket to the Internet and another to localhost. It waits for a
-     connection on both sockets, then starts proxying data between them.
-     The connector speaks SOCKS on the localhost side so that Tor can
-     connect to it using the Socks4Proxy configuration option. On
-     startup, the connector informs the facilitator that it is waiting
-     for a connection.
-  3. Flash proxy: Runs in someone's browser, in an uncensored region of
-     the Internet. The flash proxy first connects to the facilitator to
-     get a client registration. It then makes two outgoing connections,
-     one to a Tor relay and one to a waiting Tor client, and starts
-     proxying data between them.
-  4. Facilitator: Keeps track of client registrations and hands them out
-     to clients. It is capable of receiving client registrations in a
-     variety of ways. It sends registrations to flash proxies over HTTP.
-     The facilitator is responsible for matching clients to proxies in a
-     reasonable manner.
-  5. Tor relay: An ordinary Tor relay.
-
-4. Sample session
-
-  1. The restricted Tor user starts the connector program.
-  2. The restricted user starts Tor, which makes a SOCKS connection to
-     the connector.
-  3. The connector notifies the facilitator that it needs a connection.
-  4. An unrestricted user opens the web page containing the flash proxy.
-  5. The flash proxy connects to the facilitator and asks for a client.
-  6. The facilitator sends one of its client registrations to the proxy.
-  7. The flash proxy connects to a Tor relay and to the waiting client
-     connector.
-  8. The connector receives the flash proxy's connection and begins
-     relaying data between it and the Tor relay.
-
-  Later, the flash proxy may go offline. Assuming that another flash
-  proxy is available, it will receive the same client's address from the
-  facilitator, and the local Tor client will reconnect to the client
-  through it.
-
-5. Behavior of the Tor client
-
-  The Tor client must be configured to make its connections through a
-  local proxy (the connector). This configuration is sufficient:
-    UseBridges 1
-    Bridge 127.0.0.1:9001
-    Socks4Proxy 127.0.0.1:9001
-  The address given for the "Bridge" option is actually irrelevant. The
-  connector will ignore it and connect (through the flash proxy) to a
-  Tor relay. The Tor client does not have control of its first hop.
-
-6. Behavior of the connector
-
-  The connector serves two purposes: It sends a registration message to
-  the facilitator and it carries data between a flash proxy and the
-  local Tor client.
-
-  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 the
-  form:
-
-    POST / HTTP/1.0
-
-    client=[<address>]:<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
-  client address, which means the connector doesn't have to know its
-  external address.
-
-  The connector solves the impedance mismatch between the Tor client and
-  the flash proxy, both of which want to make outgoing connections to
-  the other. The connector sits in between, listens for connections from
-  both ends, and matches them together. The remote socket listens on
-  port 9000 and the local on port 9001.
-
-  On the local side, it acts as a SOCKS proxy (albeit one that always
-  goes to the same destination).
-
-7. Behavior of the flash proxy
-
-  The flash proxy polls the facilitator for client registrations. When
-  it receives a registration, it opens one connection to the given Tor
-  relay, one to the given client, and begin proxying data between them.
-
-  The proxy asks the facilitator for a registration with an HTTP GET
-  request:
-
-    GET / HTTP/1.0
-
-
-  The response code is 200 and the body looks like this:
-
-    client=[<address>:<port>]&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.
-
-8. Behavior of the facilitator
-
-  The faciliator is a HTTP server that handles client POST registrations
-  and proxy GET requests according to the formats given above. The
-  facilitator listens on port 9002.
-
-  In the current implementation, the facilitator forgets a client
-  registration after giving it to a flash proxy. The client must
-  re-register if it wants another connection later.
-
-9. Behavior of the Tor relay.
-
-  The Tor relay requires no special configuration.
diff --git a/doc/design.txt b/doc/design.txt
new file mode 100644
index 0000000..ecee83c
--- /dev/null
+++ b/doc/design.txt
@@ -0,0 +1,157 @@
+Design of flash proxies
+
+0. Problem statement
+
+  Provide access to the Tor network for users behind a restrictive
+  firewall that blocks direct access to all Tor relays and bridges.
+
+1. Overview and background
+
+  We assume the existence of an adversary powerful enough to enumerate
+  and block all public and non-public (bridge) relays. For users facing
+  such an adversary, we assume there exists a subset of reachable hosts
+  that themselves can reach the Tor network. We call this subset the
+  unrestricted Internet.
+
+  A browser-based proxy (flash proxy), running in a web page in the
+  unrestricted Internet, proxies connections between the restricted
+  Internet and the Tor network. These proxies are expected to be
+  temporary and short-lived, but their number will be great enough that
+  they can't all be blocked effectively.
+
+  The implementation of a browser-based proxy using Adobe Flash or other
+  networking technologies is complicated by restrictions that prevent it
+  being a straightforward proxy. Chief among these is the lack of
+  listening sockets. Flash and, for example, WebSockets, can only
+  initiate outgoing connections, not receive incoming ones. The flash
+  proxy can only connect to external hosts by connecting directly to
+  them. The other significant restriction is that the proxy cannot
+  connect to just any destination. A third, but less important,
+  restriction is that browser-based networking does not provide
+  low-level socket access such as control of source address.
+
+2. Components
+
+  Conceptually, each flash proxy is nothing more than a simple proxy,
+  which accepts connections from a client and forwards data to a server.
+  But because of the limited networking facilities available to an
+  in-browser application, several other pieces are needed.
+
+  1. Tor client: Is just ordinary Tor with a special configuration to
+     allow it to connect through a flash proxy. It advertises its need
+     for a connection the the facilitator, and communicates with the
+     flash proxy through the connector.
+  2. Connector: Runs on the same computer as the Tor client. It opens
+     one socket to the Internet and another to localhost. It waits for a
+     connection on both sockets, then starts proxying data between them.
+     The connector speaks SOCKS on the localhost side so that Tor can
+     connect to it using the Socks4Proxy configuration option. On
+     startup, the connector informs the facilitator that it is waiting
+     for a connection.
+  3. Flash proxy: Runs in someone's browser, in an uncensored region of
+     the Internet. The flash proxy first connects to the facilitator to
+     get a client registration. It then makes two outgoing connections,
+     one to a Tor relay and one to a waiting Tor client, and starts
+     proxying data between them.
+  4. Facilitator: Keeps track of client registrations and hands them out
+     to clients. It is capable of receiving client registrations in a
+     variety of ways. It sends registrations to flash proxies over HTTP.
+     The facilitator is responsible for matching clients to proxies in a
+     reasonable manner.
+  5. Tor relay: An ordinary Tor relay.
+
+4. Sample session
+
+  1. The restricted Tor user starts the connector program.
+  2. The restricted user starts Tor, which makes a SOCKS connection to
+     the connector.
+  3. The connector notifies the facilitator that it needs a connection.
+  4. An unrestricted user opens the web page containing the flash proxy.
+  5. The flash proxy connects to the facilitator and asks for a client.
+  6. The facilitator sends one of its client registrations to the proxy.
+  7. The flash proxy connects to a Tor relay and to the waiting client
+     connector.
+  8. The connector receives the flash proxy's connection and begins
+     relaying data between it and the Tor relay.
+
+  Later, the flash proxy may go offline. Assuming that another flash
+  proxy is available, it will receive the same client's address from the
+  facilitator, and the local Tor client will reconnect to the client
+  through it.
+
+5. Behavior of the Tor client
+
+  The Tor client must be configured to make its connections through a
+  local proxy (the connector). This configuration is sufficient:
+    UseBridges 1
+    Bridge 127.0.0.1:9001
+    Socks4Proxy 127.0.0.1:9001
+  The address given for the "Bridge" option is actually irrelevant. The
+  connector will ignore it and connect (through the flash proxy) to a
+  Tor relay. The Tor client does not have control of its first hop.
+
+6. Behavior of the connector
+
+  The connector serves two purposes: It sends a registration message to
+  the facilitator and it carries data between a flash proxy and the
+  local Tor client.
+
+  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 the
+  form:
+
+    POST / HTTP/1.0
+
+    client=[<address>]:<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
+  client address, which means the connector doesn't have to know its
+  external address.
+
+  The connector solves the impedance mismatch between the Tor client and
+  the flash proxy, both of which want to make outgoing connections to
+  the other. The connector sits in between, listens for connections from
+  both ends, and matches them together. The remote socket listens on
+  port 9000 and the local on port 9001.
+
+  On the local side, it acts as a SOCKS proxy (albeit one that always
+  goes to the same destination).
+
+7. Behavior of the flash proxy
+
+  The flash proxy polls the facilitator for client registrations. When
+  it receives a registration, it opens one connection to the given Tor
+  relay, one to the given client, and begin proxying data between them.
+
+  The proxy asks the facilitator for a registration with an HTTP GET
+  request:
+
+    GET / HTTP/1.0
+
+
+  The response code is 200 and the body looks like this:
+
+    client=[<address>:<port>]&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.
+
+8. Behavior of the facilitator
+
+  The faciliator is a HTTP server that handles client POST registrations
+  and proxy GET requests according to the formats given above. The
+  facilitator listens on port 9002.
+
+  In the current implementation, the facilitator forgets a client
+  registration after giving it to a flash proxy. The client must
+  re-register if it wants another connection later.
+
+9. Behavior of the Tor relay.
+
+  The Tor relay requires no special configuration.



More information about the tor-commits mailing list