[tor-bugs] #3594 [Tor Bridge]: Add support for SOCKS parameters in Bridge and {Client, Server}TransportPlugin lines

[Tor Bug Tracker & Wiki]

#3594: Add support for SOCKS parameters in Bridge and
{Client,Server}TransportPlugin lines
------------------------+---------------------------------------------------
 Reporter:  asn         |          Owner:                    
     Type:  defect      |         Status:  new               
 Priority:  normal      |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor Bridge  |        Version:                    
 Keywords:              |         Parent:  #3591             
   Points:              |   Actualpoints:                    
------------------------+---------------------------------------------------

Comment(by nickm):

 Replying to [comment:4 asn]:
 > Replying to [comment:3 nickm]:
 > > I believe that some other mechanism is needed for server plugin
 configuration.  But for client configuration, I don't see what's wrong
 with your example.  You wouldn't want to give shared secrets to the client
 plugin at startup time, since it needs to know which shared secrets are
 associated with which connection: different connections could need
 different shared secrets.
 >
 > Hm, I'm not sure if this would work in the case of external proxies. The
 user would have to specify on startup time, which shared secret each SOCKS
 destination should use :/

 Unless, say, Tor passed them as part of the socks handshake, right?

 > Also, the current obfs2 code sets one shared-secret per obfs2 listener.
 Of course, we can change this.

 Right; that won't work as soon as you have two bridges with two different
 secrets.

 > My biggest issue is that we won't be able to set transport options in
 transport-startup time. So for example, if a transport needs a database of
 some kind to bootstrap, we won't be able to provide it (specific example,
 morpher will need the packet size probability distribution of the target
 protocol). Many such transports might be able to handle the database
 filename being passed on connection time (morpher probably will), but
 there might be transports that will need the filename on startup (for
 precomputation, or something).

 Some options are per-connection; some are per-transport.  These are
 different things; they cannot help but be thus.

 > As you can see, I don't have a good solution. Maybe we can add support
 both for options in transport-startup (using env. vars.), and per-
 connection (using SOCKS arguments for clients, and the new Extended ORPort
 for servers? or the new extended ORPort for both?)

 Seems sane.  Extended ORPort doesn't seem to make much sense for this,
 unless you radically change what it means.

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