[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 asn):

 Replying to [comment:5 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?
 >

 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.
 >

 Yep, I was assuming that one should open two different listeners in that
 case. Guess I should make a ticket about this.

 > > 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.

 I meant the "new Extended ORPort", which is the port that will allow tor
 to pass rate-limiting information to transport proxies, etc. It was
 discussed in #3587, and I have a proposal in the making.

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