July 2012 - tor-commits - lists.torproject.org

[flashproxy/master] README copyediting and rearrangement.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 3e733e46e6e11a042732e08860e19c83328682a1 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 13:53:58 2012 -0700 README copyediting and rearrangement. --- README | 88 +++++++++++++++++++++++++++++++-------------------------------- 1 files changed, 43 insertions(+), 45 deletions(-) diff --git a/README b/README index 8b7e9b5..5fbd572 100644 --- a/README +++ b/README @@ -1,33 +1,3 @@ -== Introduction - -This is a set of tools that make it possible to connect Tor through an -browser-based proxy running on another computer. The flash proxy can be -run just by opening a web page in a browser. - -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 flash proxy and - the Tor client, and joins them together. -3. A "flash proxy," an application running in someone's web browser. -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. - -The purpose of this project is to create many, generally ephemeral -bridge IP addresses, with the goal of outpacing a censor's ability to -block them. Rather than increasing the number of bridges at static -addresses, we aim to make existing bridges reachable by a larger and -changing pool of addresses. - - -== Demonstration page - -This page has a description of the project; viewing it also turns your -computer into a flash proxy as long as the page is open. - -http://crypto.stanford.edu/flashproxy/ - - == Quick start for users You must have a version of Tor that supports pluggable transports. This @@ -39,19 +9,8 @@ But as a user you only need these files: https://gitweb.torproject.org/flashproxy.git/blob_plain/HEAD:/connector.py https://gitweb.torproject.org/flashproxy.git/blob_plain/HEAD:/torrc -There are different ways to get connected, depending on whether you are -able to receive direct TCP connections. The first method is preferred, -if you are able to configure port forwarding or receive direct -connections from the Internet. - -If you don't get a connection within 30 seconds or so, make sure someone -is viewing http://crypto.stanford.edu/flashproxy/. There aren't yet -enough operational proxies that one is available all the time. - -=== Direct TCP connection - -This is the preferred way to use a flash proxy when it's possible. The -only communication your computer makes with a fixed IP address is +You must be able to receive TCP connections in order +The only communication your computer makes with a fixed IP address is registration with the facilitator: everything else happens over ephemeral proxies. @@ -74,7 +33,45 @@ From tor you are looking for: [notice] Tor has successfully opened a circuit. Looks like client functionality is working. [notice] Bootstrapped 100%: Done. -=== Using a public connector +If you don't get a connection within 30 seconds or so, make sure someone +is viewing http://crypto.stanford.edu/flashproxy/. There aren't yet +enough operational proxies that one is available all the time. + + +== Overview + +This is a set of tools that make it possible to connect Tor through an +browser-based proxy running on another computer. The flash proxy can be +run just by opening a web page in a browser. Flash proxies are one of +several pluggable transports for Tor. + +There are five main parts. +1. The Tor client, running on someone's localhost. +2. A client transport plugin, which is a program that waits for + connections from a flash proxy and connects them to the Tor client. +3. A flash proxy, which is a JavaScript program running in someone's web + browser. +4. A facilitator, which is a server that keeps a list of clients that + want a connection and assigns those addresses to proxies. +5. A Tor relay running a server transport plugin capable of receiving + WebSocket connections. + +The purpose of this project is to create many ephemeral bridge IP +addresses, with the goal of outpacing a censor's ability to block them. +Rather than increasing the number of bridges at static addresses, we aim +to make existing bridges reachable by a larger and changing pool of +addresses. + + +== Demonstration page + +This page has a description of the project; viewing it also turns your +computer into a flash proxy as long as the page is open. + +http://crypto.stanford.edu/flashproxy/ + + +== Using a public connector Rather than running connector.py on your computer, you can use a public connector. This way is not as realistic because all your Tor traffic @@ -83,7 +80,8 @@ be easily blocked. However this is an easy way to try out the system without having to do port forwarding. $ tor ClientTransportPlugin "websocket socks4 tor-facilitator.bamsoftware.com:9999" UseBridges 1 Bridge "websocket 127.0.0.1:9001" -=== Troubleshooting + +== Troubleshooting Make sure someone is viewing http://crypto.stanford.edu/flashproxy/, or another web page with a flash proxy badge on it.

1 0

[flashproxy/master] Add tests for parse_socks_request.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit b71898a781345d57c9ba7dbe1c4f02e6a7bbbba3 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 07:09:30 2012 -0700 Add tests for parse_socks_request. --- connector-test.py | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/connector-test.py b/connector-test.py index b19fcc6..374b173 100755 --- a/connector-test.py +++ b/connector-test.py @@ -4,11 +4,29 @@ import socket import subprocess import unittest -from connector import WebSocketDecoder, WebSocketEncoder +from connector import parse_socks_request, WebSocketDecoder, WebSocketEncoder LOCAL_ADDRESS = ("127.0.0.1", 40000) REMOTE_ADDRESS = ("127.0.0.1", 40001) +class TestSocks(unittest.TestCase): + def test_parse_socks_request_empty(self): + self.assertRaises(ValueError, parse_socks_request, "") + def test_parse_socks_request_short(self): + self.assertRaises(ValueError, parse_socks_request, "\x04\x01\x99\x99\x01\x02\x03\x04") + def test_parse_socks_request_ip_userid_missing(self): + dest, port = parse_socks_request("\x04\x01\x99\x99\x01\x02\x03\x04\x00") + dest, port = parse_socks_request("\x04\x01\x99\x99\x01\x02\x03\x04\x00userid") + self.assertEqual((dest, port), ("1.2.3.4", 0x9999)) + def test_parse_socks_request_ip(self): + dest, port = parse_socks_request("\x04\x01\x99\x99\x01\x02\x03\x04userid\x00") + self.assertEqual((dest, port), ("1.2.3.4", 0x9999)) + def test_parse_socks_request_hostname_missing(self): + self.assertRaises(ValueError, parse_socks_request, "\x04\x01\x99\x99\x00\x00\x00\x01userid\x00") + self.assertRaises(ValueError, parse_socks_request, "\x04\x01\x99\x99\x00\x00\x00\x01userid\x00abc") + def test_parse_socks_request_hostname(self): + dest, port = parse_socks_request("\x04\x01\x99\x99\x00\x00\x00\x01userid\x00abc\x00") + def read_frames(dec): frames = [] while True:

1 0

[flashproxy/master] Remove some debugging logs logging function entry.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit bc27dbbe195a4fe85d3e83ea4f9b3ec2d46bbf65 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 06:37:18 2012 -0700 Remove some debugging logs logging function entry. --- connector.py | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/connector.py b/connector.py index 8a2b7e1..ed4f02c 100755 --- a/connector.py +++ b/connector.py @@ -445,7 +445,6 @@ class WebSocketRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler): MAGIC_GUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" def handle_websocket_request(fd): - log(u"handle_websocket_request") request_text = fd.recv(10 * 1024) handler = WebSocketRequestHandler(request_text, fd) if handler.error or not hasattr(handler, "path"): @@ -580,7 +579,6 @@ def parse_socks_request(data): return dest, dport def handle_socks_request(fd): - log(u"handle_socks_request") try: addr = fd.getpeername() data = fd.recv(100)

1 0

[flashproxy/master] Use an exception in parse_socks_header instead of an error return.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit a04414d0518930fbfcdb21cfb6486e1efc9ed8b4 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 06:42:32 2012 -0700 Use an exception in parse_socks_header instead of an error return. --- connector.py | 23 +++++++++++------------ 1 files changed, 11 insertions(+), 12 deletions(-) diff --git a/connector.py b/connector.py index ed4f02c..353d6b5 100755 --- a/connector.py +++ b/connector.py @@ -554,26 +554,23 @@ def grab_string(s, pos): return pos, None def parse_socks_request(data): + """Parse the 8-byte SOCKS header at the beginning of data. Returns a + (dest, port) tuple. Raises ValueError on error.""" try: ver, cmd, dport, o1, o2, o3, o4 = struct.unpack(">BBHBBBB", data[:8]) except struct.error: - log(u"Couldn't unpack SOCKS4 header.") - return None + raise ValueError("Couldn't unpack SOCKS4 header") if ver != 4: - log(u"SOCKS header has wrong version (%d)." % ver) - return None + raise ValueError("SOCKS header has wrong version (%d)" % ver) if cmd != 1: - log(u"SOCKS header had wrong command (%d)." % cmd) - return None + raise ValueError("SOCKS header had wrong command (%d)" % cmd) pos, userid = grab_string(data, 8) if userid is None: - log(u"Couldn't read userid from SOCKS header.") - return None + raise ValueError("Couldn't read userid from SOCKS header") if o1 == 0 and o2 == 0 and o3 == 0 and o4 != 0: pos, dest = grab_string(data, pos) if dest is None: - log(u"Couldn't read destination from SOCKS4a header.") - return None + raise ValueError("Couldn't read destination from SOCKS4a header") else: dest = "%d.%d.%d.%d" % (o1, o2, o3, o4) return dest, dport @@ -585,8 +582,10 @@ def handle_socks_request(fd): except socket.error, e: log(u"Socket error from SOCKS-pending: %s" % repr(str(e))) return False - dest_addr = parse_socks_request(data) - if dest_addr is None: + try: + dest_addr = parse_socks_request(data) + except ValueError, e: + log(u"Error parsing SOCKS header: %s." % str(e)) # Error reply. fd.sendall(struct.pack(">BBHBBBB", 0, 91, 0, 0, 0, 0, 0)) return False

1 0

[flashproxy/master] Add SOCKS4 reference URL.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 55c7329b70268eaf0f0fdb6dcd471740ac8cb195 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 06:57:36 2012 -0700 Add SOCKS4 reference URL. --- connector.py | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/connector.py b/connector.py index 353d6b5..333997a 100755 --- a/connector.py +++ b/connector.py @@ -553,6 +553,8 @@ def grab_string(s, pos): i += 1 return pos, None +# http://ftp.icm.edu.pl/packages/socks/socks4/SOCKS4.protocol +# https://en.wikipedia.org/wiki/SOCKS#SOCKS4a def parse_socks_request(data): """Parse the 8-byte SOCKS header at the beginning of data. Returns a (dest, port) tuple. Raises ValueError on error."""

1 0

[flashproxy/master] Shorten parse_socks_request log messages.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 49f8f59838890dc565d01a1956953d6e1359af51 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 07:09:39 2012 -0700 Shorten parse_socks_request log messages. --- connector.py | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/connector.py b/connector.py index 333997a..7a180df 100755 --- a/connector.py +++ b/connector.py @@ -563,16 +563,16 @@ def parse_socks_request(data): except struct.error: raise ValueError("Couldn't unpack SOCKS4 header") if ver != 4: - raise ValueError("SOCKS header has wrong version (%d)" % ver) + raise ValueError("Wrong SOCKS version (%d)" % ver) if cmd != 1: - raise ValueError("SOCKS header had wrong command (%d)" % cmd) + raise ValueError("Wrong SOCKS command (%d)" % cmd) pos, userid = grab_string(data, 8) if userid is None: - raise ValueError("Couldn't read userid from SOCKS header") + raise ValueError("Couldn't read userid") if o1 == 0 and o2 == 0 and o3 == 0 and o4 != 0: pos, dest = grab_string(data, pos) if dest is None: - raise ValueError("Couldn't read destination from SOCKS4a header") + raise ValueError("Couldn't read destination") else: dest = "%d.%d.%d.%d" % (o1, o2, o3, o4) return dest, dport @@ -587,7 +587,7 @@ def handle_socks_request(fd): try: dest_addr = parse_socks_request(data) except ValueError, e: - log(u"Error parsing SOCKS header: %s." % str(e)) + log(u"Error parsing SOCKS request: %s." % str(e)) # Error reply. fd.sendall(struct.pack(">BBHBBBB", 0, 91, 0, 0, 0, 0, 0)) return False

1 0

[flashproxy/master] Scrub IP addresses in connector.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit ec5fadb60d4c6a702dcc25d4e0cb40c79ea97f25 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 07:26:10 2012 -0700 Scrub IP addresses in connector. --- connector.py | 43 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 35 insertions(+), 8 deletions(-) diff --git a/connector.py b/connector.py index 7a180df..8afd0c0 100755 --- a/connector.py +++ b/connector.py @@ -46,6 +46,7 @@ class options(object): daemonize = False register = False pid_filename = None + safe_logging = True # We accept up to this many bytes from a socket not yet matched with a partner # before disconnecting it. @@ -72,13 +73,21 @@ facilitator is used; if omitted, it uses a public default. -h, --help show this help. -l, --log FILENAME write log to FILENAME (default stdout). --pidfile FILENAME write PID to FILENAME after daemonizing. - -r, --register register with the facilitator.\ + -r, --register register with the facilitator. + --unsafe-logging don't scrub IP addresses from logs.\ """ % { "progname": sys.argv[0], "local": format_addr((DEFAULT_LOCAL_ADDRESS, DEFAULT_LOCAL_PORT)), "remote": format_addr((DEFAULT_REMOTE_ADDRESS, DEFAULT_REMOTE_PORT)), } +def safe_str(s): + """Return s if options.safe_logging is true, and "[scrubbed]" otherwise.""" + if options.safe_logging: + return "[scrubbed]" + else: + return s + def log(msg): print >> options.log_file, (u"%s %s" % (time.strftime(LOG_DATE_FORMAT), msg)).encode("UTF-8") options.log_file.flush() @@ -133,6 +142,22 @@ def format_addr(addr): else: return u"%s:%d" % (host, port) +def safe_format_addr(addr): + return safe_str(format_addr(addr)) + host, port = addr + if not host: + return u":%d" % port + # Numeric IPv6 address? + try: + addrs = socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM, socket.IPPROTO_TCP, socket.AI_NUMERICHOST) + af = addrs[0][0] + except socket.gaierror, e: + af = 0 + if af == socket.AF_INET6: + return u"[%s]:%d" % (host, port) + else: + return u"%s:%d" % (host, port) + def apply_mask_numpy(payload, mask_key): @@ -419,7 +444,7 @@ def listen_socket(addr): def format_peername(s): try: - return format_addr(s.getpeername()) + return safe_format_addr(s.getpeername()) except socket.error, e: return "<unconnected>" @@ -591,7 +616,7 @@ def handle_socks_request(fd): # Error reply. fd.sendall(struct.pack(">BBHBBBB", 0, 91, 0, 0, 0, 0, 0)) return False - log(u"Got SOCKS request for %s." % format_addr(dest_addr)) + log(u"Got SOCKS request for %s." % safe_format_addr(dest_addr)) fd.sendall(struct.pack(">BBHBBBB", 0, 90, dest_addr[1], 127, 0, 0, 1)) # Note we throw away the requested address and port. return True @@ -770,15 +795,15 @@ def main(): for fd in rset: if fd == remote_s: remote_c, addr = fd.accept() - log(u"Remote connection from %s." % format_addr(addr)) + log(u"Remote connection from %s." % safe_format_addr(addr)) websocket_pending.append(TimeoutSocket(remote_c)) elif fd == local_s: local_c, addr = fd.accept() - log(u"Local connection from %s." % format_addr(addr)) + log(u"Local connection from %s." % safe_format_addr(addr)) socks_pending.append(local_c) register() elif fd in websocket_pending: - log(u"Data from WebSocket-pending %s." % format_addr(addr)) + log(u"Data from WebSocket-pending %s." % safe_format_addr(addr)) protocols = handle_websocket_request(fd) if protocols is not None: wrapped = RemoteSocket(fd, protocols) @@ -789,7 +814,7 @@ def main(): websocket_pending.remove(fd) report_pending() elif fd in socks_pending: - log(u"SOCKS request from %s." % format_addr(addr)) + log(u"SOCKS request from %s." % safe_format_addr(addr)) if handle_socks_request(fd): wrapped = LocalSocket(fd) locals.append(wrapped) @@ -833,7 +858,7 @@ def main(): report_pending() if __name__ == "__main__": - opts, args = getopt.gnu_getopt(sys.argv[1:], "f:hl:r", ["daemon", "facilitator=", "help", "log=", "pidfile=", "register"]) + opts, args = getopt.gnu_getopt(sys.argv[1:], "f:hl:r", ["daemon", "facilitator=", "help", "log=", "pidfile=", "register", "unsafe-logging"]) for o, a in opts: if o == "--daemon": options.daemonize = True @@ -848,6 +873,8 @@ if __name__ == "__main__": options.pid_filename = a elif o == "-r" or o == "--register": options.register = True + elif o == "--unsafe-logging": + options.safe_logging = False if len(args) == 0: options.local_addr = (DEFAULT_LOCAL_ADDRESS, DEFAULT_LOCAL_PORT)

1 0

[flashproxy/master] Move design.txt to doc.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 210d5b2e98e3b6deff480310cd7e424c962fd928 Author: David Fifield <david(a)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.

1 0

[flashproxy/master] Remove swfcatsim idea.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 400238deefc640fe29aa8e64487b2aab51b034fd Author: David Fifield <david(a)bamsoftware.com> Date: Sun Jun 24 21:36:03 2012 -0700 Remove swfcatsim idea. --- notes.txt | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/notes.txt b/notes.txt index 61babdc..b521bef 100644 --- a/notes.txt +++ b/notes.txt @@ -9,13 +9,6 @@ reconnecting through a new proxy. Tor remembers the host fingerprint from the first connection (to the bridge it thinks is at 127.0.0.1) and balks at connecting to the same address with a different fingerprint. -Could be useful to have a swfcatsim.py program. This would simulate -a swfcat instance (perhaps without the crossdomain stuff), providing -a bridge with a lifetime randomly chosen from some distribution. (For -example: "simulate proxies connecting according to this Poisson -distribution and staying connected according to this exponential -distribution.") - == How to use with an SSH proxy Start swfcat, giving it a relay parameter pointing to your SSH server.

1 0

[flashproxy/master] Remove understanding of RTMFP regs from facilitator.
by dcf＠torproject.org 04 Jul '12

04 Jul '12

commit 4fe3bf784716eb90b2f240cd686dce6849c5d0e3 Author: David Fifield <david(a)bamsoftware.com> Date: Wed Jul 4 04:10:48 2012 -0700 Remove understanding of RTMFP regs from facilitator. --- facilitator.py | 19 ------------------- 1 files changed, 0 insertions(+), 19 deletions(-) diff --git a/facilitator.py b/facilitator.py index 3e7ca09..83de49b 100755 --- a/facilitator.py +++ b/facilitator.py @@ -129,22 +129,6 @@ class TCPReg(object): else: return False -class RTMFPReg(object): - def __init__(self, id): - self.id = id - - def __unicode__(self): - return u"%s" % self.id - - def __str__(self): - return unicode(self).encode("UTF-8") - - def __cmp__(self, other): - if isinstance(other, RTMFPReg): - return cmp(self.id, other.id) - else: - return False - class Reg(object): @staticmethod def parse(spec, defhost = None, defport = None): @@ -163,9 +147,6 @@ class Reg(object): host, port = socket.getnameinfo(addrs[0][4], socket.NI_NUMERICHOST | socket.NI_NUMERICSERV) return TCPReg(host, int(port)) - if re.match(ur'^[0-9A-Fa-f]{64}$', spec): - return RTMFPReg(spec) - raise ValueError("Bad spec format: %s" % repr(spec)) class RegSet(object):

1 0