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

 Some time ago I promised to write up a bit of an explanation for why
 "cram[ming] all the actual addresses into the socks username/password"
 isn't great for !StegoTorus.

 A full configuration for the !StegoTorus client [assuming the presence of
 a bunch of things that still haven't actually been implemented] is pretty
 heavyweight.  It looks something like this -- format not to be taken as
 set in stone, but contents pretty much all necessary --

 {{{
 bridge example_name {
   tor_id "ca8a aab2 05b3 5b13 5afc 2782 b891 b555 c6fa f824"
   key "IQt2ejUA1gD927mLFXGN1daxojRa,qcjh1z8mduWejiM6IT8PdQle/UJq"
   window [1356824532 1356910932]
   ticket "gRT3RayKU4epkB7xPJV/p1Pm0G7faYA09vG4FAhkrqU="
   addresses {
     "192.0.2.1:80" {
       steg http
       formats [html js css pdf swf]
       maxconn 6
       maxrate 8000
     }
     "192.0.2.2:443" {
       steg embed
       template spdy
       maxconn 2
       maxrate 65535
     }
     "192.0.2.3:6666" {
       steg irc
       maxconn 1
       maxrate 1000
     }
     // five to ten more of these
   }
 }
 }}}

 As written, that's 586 bytes long; obviously it could be more compact, but
 as a ballpark estimate of how much space a good wire format would take,
 zlib only manages to compress it down to 369 bytes.  So we are already
 uncomfortably close to the 512-byte upper limit on a SOCKS5
 username/password pair; I suspect adding the anticipated five to ten more
 listener addresses would put it over the limit.  SOCKS4a doesn't have that
 limit but I'm worried about compatibility issues; most of the SOCKS code
 out there probably blithely assumes short usernames and passwords.  (We do
 control both sides of the SOCKS dialogue, so maybe this concern is
 unwarranted.)

 In addition, having SOCKS support in !StegoTorus ''at all'' is
 inconvenient.  It's only about 800 lines of code (not counting tests), but
 they add complexity to the connection setup and teardown logic, which has,
 over the lifetime of the project, been by far the most troublesome
 component to get right.  There are still several known bugs in there and
 no doubt more I haven't even noticed yet.  Removing SOCKS would allow (in
 my opinion) a significant and worthwhile simplification of that component.

 Configuring !StegoTorus independently of Tor may also prove more
 convenient in the larger picture.  The "DEFIANCE" architecture that was
 presented at FOCI last summer contemplates packaging up pluggable-
 transport configurations as "network entry tickets" and delivering them to
 clients in a semi-automated manner.  So there would be a controller
 process that would receive basically the above configuration blob from the
 network. In the current pluggable transport design, it would have to be
 parsed, repackaged as a bridge descriptor in Tor's dynamic configuration,
 and then repackaged again to hand off to the transport plugin.  Feeding it
 directly to the pluggable transport instead (as a file in the filesystem,
 presumably) saves two data-reformatting operations.  Furthermore, it means
 !StegoTorus only needs one configuration parser, and the "ACS dance"
 client needs none at all.

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