[tor-bugs] #7153 [Pluggable transport]: Don't require pluggable transport proxies to be SOCKS proxies

[Tor Bug Tracker & Wiki]

#7153: Don't require pluggable transport proxies to be SOCKS proxies
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  asn
     Type:  project              |         Status:  new
 Priority:  normal               |      Milestone:     
Component:  Pluggable transport  |        Version:     
 Keywords:  SponsorF20130228     |         Parent:     
   Points:                       |   Actualpoints:     
---------------------------------+------------------------------------------

Comment(by dcf):

 Replying to [comment:9 nickm]:
 > Zack, David -- I'm not getting a great sense here what interface you
 actually want, beyond "Not the current one!"  Is there a
 flashproxy/stegotorus document that explains your preferred solution here?
 (Please forgive me if it's described above and I'm just not seeing it.)

 The current model mostly works fine for flash proxy. Being SOCKS works
 fine. The `Bridge storus1 direct` example in the description, I don't know
 how flash proxy would use something like that.

 What flash proxy could use is a way to inform Tor dynamically of the
 bridges currently available. The way it works now is
  1. You put
    {{{
 Bridge websocket 0.0.1.0:1
 ClientTransportPlugin websocket exec ./flashproxy-client --register
    }}}
    in your `torrc` and start Tor.
  2. The flash proxy client transport plugin does its rendezvous, but no
 proxy connections come in immediately (takes about a minute).
  3. Tor makes a SOCKS request for the fake bridge address 0.0.1.0:1.
  4. The flash proxy client transport plugin accepts the SOCKS request even
 though it doesn't have any proxies yet. Tor sends a few hundred bytes at
 this point, which the transport plugin buffers.
  5. A minute later, about 10 proxy connections come in, mostly all at
 once. The transport plugin picks one of them, flushes its buffer over the
 proxy, and proxies as long as the proxy exists. When the proxy
 disconnects, the transport plugin switches to another already existing
 connection, but Tor doesn't notice this fact and thinks it's the same
 bridge at 0.0.1.0:1.
 Note in the above how there is only ever one SOCKS connection open at a
 time. Nine out of ten proxies sit idle while one of them is being used.

 This is what would be better:
  1. You put
    {{{
 ClientTransportPlugin websocket exec ./flashproxy-client --register
    }}}
    in your `torrc` and start Tor. Notice you don't configure any bridges
 (because none exist yet).
  2. The transport plugin does its rendezvous and waits.
  3. Tor ''doesn't'' make a SOCKS connection because it knows of no bridges
 yet.
  4. About 10 proxy connections come in. The transport plugin informs Tor
 of each of them, over a control port or something. Think of it as
 effectively dynamically adding new bridge lines:
     {{{
 Bridge websocket X.X.X.X:X
 Bridge websocket Y.Y.Y.Y:Y
 Bridge websocket Z.Z.Z.Z:Z
 ...
     }}}
     Where X.X.X.X:X etc. are the actual proxy IP addresses and ports that
 have just been learned. (Or they could be made up or hashed, it doesn't
 really matter.)
  5. Tor now knows of 10 bridges it can make SOCKS requests for. If Tor
 asks for a connection to X.X.X.X:X, for example, the transport plugin
 would match the address to one of its existing proxy connections, and
 report SOCKS success to Tor. Having an address as a name for the
 connection allows Tor to manage bandwith per flash proxy or whatever.
  6. As flash proxies disconnect, the transport plugin can dynamically
 ''remove'' those bridge lines that it added previously, again over some
 control channel. Tor notices when a bridge goes away.
 So the number of parallel SOCKS connections could be as high as the
 current number of flash proxies, and Tor would be able to manage bandwidth
 and keyids independently for each of them.

 In summary, if there were a way for a transport plugin to tell Tor that
 there is a new bridge, and tell Tor when a bridge no longer exists, it
 would be all we need. All the SOCKS infrastructure wouldn't have to
 change.

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