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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 arma):

 Right -- the main topic of this ticket is to see if it's time to revise
 the set of specified (supported) ways that Tor can delegate connections to
 bridges.

 When we started, we were generalizing from the obfsproxy example, where
 each pluggable transport has a local address it listens on, and you
 connect and tell it your desired bridge address in a socks handshake, and
 if there's more you want to say, you sneak it in via the socks
 username/password field of the socks handshake.

 Now we have two new data points, neither of which fit that model well. The
 first is Stegotorus, where the parameters we want to sneak in don't even
 fit in the username/password field, and also Stegotorus doesn't want to
 hear the address we tell it. The second is Flashproxy, where there are no
 parameters, but also it ignores the address we tell it.

 So the question for this ticket is: now that we have these three data
 points, is the socks-handshake-with-extra-stuff-in-username/password still
 the best model to recommend? If so, should we also recommend (aka specify
 and support) how best to behave if you're one of those two other data
 points?

 Stegotorus has been developed under the model that something else would
 start it as an external proxy, with its own configuration. It has never
 fit well in the managed proxy model. Zack proposes one hack to make it fit
 a bit better. Can we think of better ones? Note that we're still
 *starting* the Stegotorus process with its parameters, rather than telling
 it parameters for a given connection around the time we make the
 connection; that seems klunky to me, since I think it means tearing down
 the Stegotorus process and launching another one, when you want to talk
 differently to your bridges (i.e. when you want to start using a new
 network entry ticket).

 David wants to go a step in a different direction, where a given bridge
 address is actually many bridges, and he doesn't know which ones they are
 because his pluggable transport will only find out once it receives the
 connections from them. His "ignore the address" hack sounds less
 crazypants than Stegotorus's, mostly I guess since he doesn't have any
 other parameters he wants to pass in, but also because his flashproxy
 client stub shouldn't need a restart when you change bridges.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7153#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs