[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:  defect               |         Status:  new
 Priority:  normal               |      Milestone:
Component:  Pluggable transport  |        Version:
 Keywords:                       |  Actual Points:
Parent ID:                       |         Points:
---------------------------------+---------------------
 Currently, client-side pluggable transports (like scramblesuit) that need
 parameters (like shared-secrets, etc.) are supposed to get them through
 the SOCKS protocol. Specifically, Tor is supposed to shove the shared-
 secret in the username/password fields of the SOCKS handshake.

 Apart from the solution being ugly and super hacky it also imposes a size
 limit to our parameters, since SOCKS5 has a maximum length of 512 bytes of
 username/password (#9163). SOCKS5 is needed since it's the only SOCKS
 version that officially supports IPv6.

 As a more permanent solution than #9163 we should think of how to improve
 this situation. At least three ways come in mind:

 a) We use the reserved `METHOD` field of the SOCKS protocol to define our
 own authentication method (see section 3 of
 http://csocks.altervista.org/rfc/rfc1928.txt). Then we use this new
 authentication method to pass parameters to pluggable transports.

 This seems cleaner than before, but we still piggyback on the
 authentication mechanism (which means that if we ever wanted to password
 protect obfsproxy's SOCKS listener we can't) so it's not perfect. Also
 many libraries might not support reserved authentication methods, which
 means that some monkey patching will be needed.

 b) We design and specify our own SOCKS protocol. SOCKS kinda sucks for PTs
 anyway (#7153). I don't like this idea, because I don't like homebrewed
 protocols and it will require significant specification/development
 efforts to replace all the current uses of SOCKS in PTs.

 c) We write yet another metadata protocol that happens after SOCKS but
 before application-layer data is transferred to obfsproxy. It's the
 equivalent of Extended ORPort for the client-side, and it might be useful
 for other information apart from client-side parameters. I don't like this
 solution either.

 d) We define an environment varialbe similar to
 `TOR_PT_SERVER_TRANSPORT_OPTIONS` but for the client-side. Unfortunately,
 the client-side parameters are dynamic (parameters are different for
 different destination addresses) so the environment variable will also
 need to include the destination bridge address along with the parameter.
 Furthermore, if we ever wanted to make parameters completely dynamic (so
 that they change after Tor startup) this solution might complicate
 matters. Still this is not terribly bad (since we already parse env vars
 and we already do something similar on the server side), but it's not good
 either.

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