[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:     
---------------------------------+------------------------------------------

Comment(by dcf):

 Replying to [comment:4 asn]:
 > FWIW, flashproxy seems to be doing the same thing as stegotorus:
 > https://gitweb.torproject.org/user/dcf/flashproxy.git/blob/transport
 :/flashproxy-client#l71

 This is true. In the configuration we use an IP address that tries to be
 obviously fake: 0.0.1.0:1. (The address 0.0.0.0 doesn't work because `tor`
 uses it as a reserved value. I'm guessing I also tried 0.0.0.1 but it
 didn't work because SOCKS4a uses addresses of that form. Similarly a port
 of 0 is problematic.)

 I have thought about, but haven't tested, using multiple `Bridge` lines
 with different fake addresses. They would in fact all be going to the same
 websocket bridge, but they would be going through different flash proxies
 (unknown in advance).
 {{{
 ClientTransportPlugin websocket exec ./flashproxy-client --register
 UseBridges 1
 Bridge websocket 0.0.1.0:1
 Bridge websocket 0.0.1.1:1
 Bridge websocket 0.0.1.2:1
 Bridge websocket 0.0.1.3:1
 Bridge websocket 0.0.1.4:1
 }}}

 I can think of two things that would make things easier for flash proxy.
 The first would be a way for `flashproxy-client` to advise `tor` of how
 many virtual bridges (flash proxies) are currently available. We aim to
 keep about five of these, but only use one at a time. We could get better
 performance by running different circuits over different proxies.

 The second is a solution for #3292. `tor` currently freaks out and refuses
 to connect if its bridge at 0.0.1.0:1 changes fingerprint. This can be
 expected to happen because 0.0.1.0:1 is not the bridge's real address, but
 a virtual address which can refer to different bridges at different times.
 We currently work around this by having only one websocket bridge the
 facilitator knows about.

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

 What metadata would be passed here? Am I correct in assuming that
 stegotorus takes a list of addresses on the command line, and that this
 information would be passed as part of a SOCKS handshake instead. This
 wouldn't make any difference for flash proxy, because we don't know any
 flash proxy addresses a priori, so we couldn't give them to the transport
 even if we wanted to.

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