[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7153 [Pluggable transport]: Don't require pluggable transport proxies to be SOCKS proxies
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs