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

 Replying to [comment:20 zwol]:
 > Sorry for dropping the ball on this again.
 >
 > Nick's proposal appears almost entirely orthogonal to the problems
 StegoTorus has with doing SOCKS; it appears mostly about improving
 communication between Tor and a controller process, which ST isn't.  The
 "configuration may be too large for a SOCKS connection request" issue,
 which is probably the most important, is only addressed by saying that
 it's okay to require use of SOCKS4a (which has no official upper limit)
 and I do not feel comfortable relying on that;

 Why not?  SOCKS4a support is supposed to be guaranteed.  There's no reason
 I can see that a pluggable transport is required to support SOCKS5.

 I'm happy allowing Tor to support an arbitrarily large upper limit for
 socks4a, or to define an upper limit of 128KB, or whatever makes sense.

 > the actual implementation in ST right now does have an upper limit
 (chosen arbitrarily, according to comments) and I am concerned that
 pluggable transports may all pick different arbitrary cutoffs and we'll
 have a big mess.  My other concerns (number of marshal/unmarshal passes,
 additional implementation costs of having SOCKS code at all) do not seem
 to have been addressed at all.

 There is no way for process A to communicate with process B without some
 marshalling/unmarshalling, of course, but things could be simpler.  I'll
 scan the above to see if there are any ideas for a simpler proposal.

 Also, SOCKS4a is, like, pretty darn simple.  Pluggable transports are not
 required to support all versions of SOCKS; any version of socks is okay.
 Is the objection to all versions of SOCKS, or just SOCKS5?

 > I don't understand the stated objection to a "just start talking OR on
 this local port" bridge method:
 >
 > > (Tor really needs to have some idea when it's making connections to
 the same bridge or not.)
 >
 > Any given ST local-port talks to one and only one bridge, whose key
 fingerprint is (optionally) specified on the "direct" Bridge line.  This
 would seem to be a non-problem.

 Ah, so this sounds like ST wants more to be treated like a bridge than
 like a pluggable transport.  If it wants to get its parameters out-of-
 band, and it wants to have one local port per bridge, then it makes more
 sense to configure Tor with
 {{{
   Bridge 127.0.0.1:34325
   Bridge 127.0.0.1:34311
   Bridge 127.0.0.1:34415
 }}}
 or whatever ports ST is listening on.

 But I guess that must not work for whatever reason.  I'll re-read
 everything you've written here one more time and see if I can figure it
 out.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7153#comment:21>
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