[tor-bugs] #10671 [Pluggable transport]: Pluggable Transports: Improve method of transferring parameters to client-side transports

[Tor Bug Tracker & Wiki]

#10671: Pluggable Transports: Improve method of transferring parameters to client-
side transports
-------------------------------------+--------------------
     Reporter:  asn                  |      Owner:  asn
         Type:  enhancement          |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:
Actual Points:                       |  Parent ID:  #10629
       Points:                       |
-------------------------------------+--------------------

Comment (by yawning):

 Replying to [comment:5 asn]:
 > I like your approach Yawning. We will also need to define what happens
 if Tor wants to do the 0x80 `SOCKS PT` method but it's not sure whether
 the PT supports it. We will probably need to define a
 `TOR_PT_CMETHOD_PROXY_TYPES` environment variable like David suggested
 (and the PT will have to advertise `socks5pt` support or something). I
 guess this is not too bad but not too good either.

 We do?  The SOCKS5 protocol negotiates, so this all is transparent.

 With a Tor that supports our extension:
 Tor->PT: 0x05 0x03 0x00 0x02 0x80 (SOCKSv5, 3 auth methods, None,
 Username/Password, Tor Extended)

 Ext capable PT->Tor: 0x05 0x80 (SOCKSv5, we will use 0x80)
 Old or argument less PT->Tor: 0x05 0x02 (SOCKSv5, we will use
 Username/Password)

 Tor can them make the decision as to if the PT can be used.  IMO doing it
 on a per bridge basis when the relevant bridge is actually used is
 preferable, but it can be done via the pt config protocol by having the PT
 declare itself as "socks5pt".  I don't see a reason for another env var in
 any case, Tor binaries that support the extension can and should just
 request the method as needed.

 Something like (somewhere deep in the guts of Tor):
  * If authentication is required, request auth 0x80 (We've coded ourselves
 into a corner wrt using Username/Password for actual auth since it would
 break backward compatibility).
  * If the bridge line has 0 arguments, request auth 0x00 (None required)
  * If the bridge line has arguments that fit into the old style config
 space, request auth 0x02 and 0x80 (Either works, this should allow old PTs
 to continue to work unless their SOCKS5 implementation is garbage).
  * If the bridge line has arguments that requires the extended space,
 request auth 0x80.

 After some thought our auth method should probably allow ULEN/PLEN fields
 to be 0 (with UNAME/PASSWD omitted, instead of requiring at least 1 byte).
 I just blindly cribbed those fields from the RFC, but requiring them is
 somewhat nonsensical for our common use case.

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