[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:3 dcf]:
 > e) We make `socks4a` one of the possible `CMETHOD` SOCKS types (along
 with the existing `socks4` and `socks5`), and pass IPv6 addresses as if
 they were host names. Benefits: works with IPv6 (like `socks5`) and has
 unlimited credentials length (like `socks4`). Another benefit: would allow
 Tor to pass host names to pluggable transports (currently it always pre-
 resolves names that you put in a `Bridge` line).

 As long as Tor ignores the DSTIP field in the PT->Tor socks response, then
 this would work.  I don't see Tor needing the remote IP for anything, but
 I haven't given it massive amounts of thought (Maybe if we allow name
 resolution it could do something with it?).

 Personally I'm in favor of "a" since it will:
  * Support binary data
  * Be backwards compatible (The only failure case is PTs that require
 extended config with an old Tor, but ALL currently deployed Tor binaries
 can't use such PTs regardless of auth method anyway)
  * Still allow password protecting the SOCKS endpoint (though only for
 clients that support the extension auth method, so new PT + old Tor = no
 passwords for you)

 Something like:
 {{{
 METHOD - 0x80 (Reserved range is 0x80-0xFE)

 Fields common to RFC 1929 have the same values/definitions.
 +-----+------+----------+------+----------+--------+------------+
 | VER | ULEN |  UNAME   | PLEN |  PASSWD  | EXTLEN |   EXTDATA  |
 +-----+------+----------+------+----------+--------+------------+
 |  1  |  1   | 1 to 255 |  1   | 1 to 255 |   2    | 0 to 65535 |
 +-----+------+----------+------+----------+--------+------------+

 VER: 0x01 (Also in RFC 1929, but this is our auth method version)

 EXTLEN: Length of EXTDATA in network byte order (64k is enough for
 anybody?)

 EXTDATA: PT specific per-endpoint configuration data
 }}}

 Possible changes:
  * Change EXTLEN/EXTDATA to Key/Value pairs (NR_EXTDATA, KLEN, KEY, VLEN,
 VAL, ...)
  * If it is conceivable that PTs will use more that 64k of per bridge
 config information, then EXTLEN could be 4 bytes.  I would hate to see the
 bridgeline for such a transport though.

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