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

 Okay, so here's my suggestions for trying to make everybody a bit more
 happy here.  If people like this, I'll turn it into a proposal and a set
 of tickets.

 === Nick's Proposal, v1 ===
  * Extract variant of the easy parts of Proposal 199, so that pluggable
 transports can also act as bridge managers.  The parts I propose to build
 are:
     * When being launched, a managed proxy can find out a tor controller
 port, along with a password or cookie location to use to authenticate to
 Tor. An external proxy can get this information too.  Getting this
 information means that you're acting as a bridge manager.
     * After making a controller connection to Tor, the bridge managers can
 use SETCONF to tell Tor about bridge information.
  * Change the semantics of setting "UseBridges 1" when no bridges are
 configured.  Right now, it's an error. I propose that instead it have the
 same effect as
  * Add a new __Bridge configuration option. It will have the same effect
 as Bridge, but (because it starts with __) its values won't be saved by a
 SAVECONF command.
  * Add a new ADDCONF / DELCONF command to help maintain the Bridges and
 __Bridges configuration options. It will only operate on a linelist.
 DELCONF will only remove lines when they're provided verbatim.
  * Clarify that it's okay to be a proxy that only supports SOCKS4a, so
 that nobody goes out of their way to build SOCKS5 support when they don't
 need to.
  * Add a new SOCKS reply code meaning "proxy not ready yet; try later."
  * Let's add a weight parameter to bridges.

 Additionally, I'm suggesting some items for us ''not'' to do. I think most
 of these are unnecessary or unwise; I'm listing them only because I was
 considering them for at least a while, and I want to know if they're
 better than I thought.
  * Let's not add a new not-SOCKS connection mechanism. (Tor really needs
 to have some idea when it's making connections to the same bridge or not.)
  * Let's not add a new mechanism other than the control protocol for
 bridge managers to tell Tor what the bridges are. (More protocols make
 everybody sad.  The subset of the Tor control protocol that's needed for
 this would seem relatively small.)
  * Let's not reduce the question of "what bridges are there" to "how many
 bridges can be accessed via plugin X". (Needless complexity.)
  * Let's not introduce a new variant of the control protocol where Tor
 connects to bridge manager and then they authenticate. (Needless
 complexity)

 How far would this take us?

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