[tor-bugs] #7167 [Pluggable transport]: Combine traffic obfuscation with address diversity of flash proxy

[Tor Bug Tracker & Wiki]

#7167: Combine traffic obfuscation with address diversity of flash proxy
---------------------------------+-----------------------------------------
     Reporter:  karsten          |      Owner:  asn
         Type:  project          |     Status:  needs_revision
     Priority:  normal           |  Milestone:
    Component:  Pluggable        |    Version:
  transport                      |   Keywords:  SponsorF20131101 flashproxy
   Resolution:                   |  Parent ID:
Actual Points:                   |
       Points:                   |
---------------------------------+-----------------------------------------

Comment (by dcf):

 Replying to [comment:26 dcf]:
 > I started Mk. II of the server transport in my repo at
 https://www.bamsoftware.com/git/obfs-flash.git. To build it, do
 > {{{
 > export GOPATH=$(pwd)
 > go get # fetches the pt library
 > make
 > }}}
 > This version is pretty much a port of the Python Mk. I.V. The next step
 is to have it open its own listener and connect to Tor using the
 ExtORPort.
 >
 > This is now what's running at tor1.bamsoftware.com:9500
 (173.255.221.44:9500).

 I pushed a rough draft of Mk. II that does extended ORPort. The program
 opens an external and an internal listener in addition to starting the two
 subproxies. The external listener listens on the bindaddr and forwards
 data to the proxy chain. The proxy chain is configured to finally connect
 to the internal listener. The internal listener forwards data to the
 (extended) ORPort. A FIFO queue (implemented as a Go
 [http://golang.org/doc/effective_go.html#channels channel]) stores the
 external connecting IP addresses so they can be given to the extended
 ORPort by the internal listener.

 It seems to do the extended USERADDR thing right, at least when testing
 locally:
 {{{
 Aug 29 19:45:09.000 [debug] connection_ext_or_process_inbuf(): Got
 Extended ORPort data.
 Aug 29 19:45:09.000 [debug] connection_ext_or_handle_cmd_useraddr():
 Received USERADDR.We rewrite our address from '[scrubbed]:35967' to '[s
 crubbed]:38715'.
 Aug 29 19:45:09.000 [debug] connection_ext_or_process_inbuf(): Got
 Extended ORPort data.
 Aug 29 19:45:09.000 [debug] connection_ext_or_process_inbuf(): Got
 Extended ORPort data.
 Aug 29 19:45:09.000 [debug] connection_ext_or_process_inbuf(): Received
 DONE.
 }}}

 I want to polish and refactor the code yet.

 What I am most concerned about is the scenario when something connects to
 the external listener (and an address is queued), but something goes wrong
 in the proxy chain (for example the WebSocket handshake is bad) and
 there's no following connection to the internal listener. We will have an
 orphan address in the queue that will be associated with the next
 connection that survives to the internal listener. In the current
 implementation, I supposed this will eventually result in deadlock,
 because the size of the FIFO is limited. Perhaps we can age and expire
 queue entries.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7167#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online