[tor-commits] [flashproxy/master] design doc: add a section discussing the protocols explicitly, and reword the component section to be a bit more precise

[dcf at torproject.org]

commit 3683a099d7190f5d117de084006a958d4c7f8aba
Author: Ximin Luo <infinity0 at gmx.com>
Date:   Wed Jul 31 19:58:19 2013 +0100

    design doc: add a section discussing the protocols explicitly, and reword the component section to be a bit more precise
---
 doc/design.txt |   42 +++++++++++++++++++++++++++++-------------
 1 file changed, 29 insertions(+), 13 deletions(-)

diff --git a/doc/design.txt b/doc/design.txt
index 7f1e548..bc0f377 100644
--- a/doc/design.txt
+++ b/doc/design.txt
@@ -35,18 +35,12 @@ Design of flash proxies
   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 client transport plugin.
-  2. Client transport plugin: 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 transport plugin speaks SOCKS on
-     the localhost side so that it can work as a pluggable transport for
-     Tor using the ClientTransportPlugin configuration option. On
-     startup, the transport plugin registers with the the facilitator to
-     inform the facilitator that it is waiting for a connection.
+  1. Tor client: with a ClientTransportPlugin config option to allow it to
+     use the flashproxy transport client.
+  2. Client transport plugin: Runs on the same computer as the Tor client.
+     On startup, it registers with the facilitator to inform that it is
+     waiting for a connection from a flash proxy. When this is received,
+     it starts proxying data between it and the local Tor client.
   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,
@@ -57,7 +51,29 @@ Design of flash proxies
      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.
+  5. Tor relay: with a ServerTransportPlugin config option to allow it to
+     use the flashproxy transport server.
+  6. Server transport plugin: Waits for a connection from a flash proxy and
+     proxies data between it and the local Tor relay.
+
+3. Protocols
+
+  The numbers refer to the same components as in sect 2 above. Arrows
+  indicate the direction of the initial TCP connection.
+
+  1>2. Pluggable transport, client-side. See core tor docs for details.
+  2>4. Secure rendezvous using a variety of custom methods; see
+       facilitator-howto.txt for details. This must be very hard to censor,
+       e.g. using a popular web service over HTTPS.
+  3>4. Custom protocol specific to flashproxy, where each flashproxy polls
+       a facilitator for client registrations.
+  2<3. WebSocket. This must be very hard to censor, which may require
+       additional transformations to the underlying data stream. Note
+       that this stream is controlled by the source client, not the flash
+       proxy; in a plain flashproxy-only channel, it is as described in
+       websocket-transport.txt.
+  5<3. WebSocket.
+  5>6. Pluggable transport, server-side. See core tor docs for details.
 
 4. Sample session