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

 Replying to [comment:21 nickm]:
 > Replying to [comment:20 zwol]:
 > > Sorry for dropping the ball on this again.
 > >
 > > [...] 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.

 It is specifically the "no official upper limit" thing that I am not
 entirely comfortable relying on.  It appears to be a thing left
 accidentally unspecified, rather than an intentional feature, as I read
 the SOCKS4a spec.

 It is true that we control both ends of the communication here, so maybe
 this is not as much of a problem as it seems.  At the least I think a
 minimum-maximum number should be written into the pluggable transport
 spec.

 > There is no way for process A to communicate with process B without some
 marshalling/unmarshalling, of course, but things could be simpler.

 Lemme try to unpack that a little.  We have (abstractly) three processes
 running on the same machine: Tor, the controller, and the transport.
 Right now, as I understand it, the intention is that the controller
 configures the transport by poking Bridge lines into Tor's in-memory
 configuration, and Tor then turns around and hands that configuration to
 the transport over SOCKS.

 What I'm saying is that it is somewhat more convenient for ST (in
 particular, ST as a component of the "DEFIANCE" system) if the controller
 can configure the transport directly rather than having to use the Tor
 process as a registry.  It's not a huge thing, but it is the difference
 between one or two configuration parsers in ST, and zero or one
 configuration reformatters in the controller.  (Note that this is all
 somewhat hypothetical, as ST currently has no configuration parser and I
 never did get around to merging George's managed proxy implementation from
 obfsproxy.  It is possible that this objection would evaporate if looked
 at more seriously.  It is also possible that it would mushroom.)

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

 This objection is to having *any* SOCKS support, and is strictly on
 implementation-complexity grounds.  As I said way up top, SOCKS is ~800
 lines of code, which might not *seem* like a big deal, but it intrudes
 itself on the single most conceptually complicated and (consequently) most
 bug-ridden aspect of ST, namely connection setup.

 I rate it as highly probable that SOCKS is part of why ST's reliability
 never got to where I could actually finish the crypto layer.

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

 I don't think anyone has ever suggested this before.  Off the top of my
 head I don't see any reason why it wouldn't work.

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