[tor-bugs] #7153 [Pluggable transport]: Don't require pluggable transport proxies to be SOCKS proxies

[Tor Bug Tracker & Wiki]

#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:  SponsorZ             |         Parent:     
   Points:                       |   Actualpoints:     
---------------------------------+------------------------------------------
Changes (by asn):

 * cc: dcf (added)


Comment:

 FWIW, flashproxy seems to be doing the same thing as stegotorus:
 https://gitweb.torproject.org/user/dcf/flashproxy.git/blob/transport
 :/flashproxy-client#l71
 I'm CCing David in case he has any opinions on the matter.

 Myself, I'm not sure yet which way of solving this issue is better:

 a) Use the SOCKS5 username/password covert channel to transfer multiple
 addresses.
    Is this hack sufficiently future-proof? Will there be pluggable
 transports in the future that won't be satisfied by such a solution? How
 do we pass other parameters to the pluggable transport if the
 username/password covert channel is occupied by addresses? Are 512 bytes
 enough?

 b) Implement Zack's `direct` suggestion.
    This seems like an OK-ish solution, if the pluggable transport proxy
 always has a way of acquiring bridge addresses. Will this be true in the
 future?

 c) Other solutions.
    Like leaving the situation as it currently is, or sticking metadata in
 the SOCKS handshake that allows the pluggable transport proxy to find the
 bridge addresses on its own.

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