[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: SponsorF20130228 | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by dcf):
Replying to [comment:16 nickm]:
> Okay, so here's my suggestions for trying to make everybody a bit more
happy here. If people like this, I'll turn it into a proposal and a set
of tickets.
>
> === Nick's Proposal, v1 ===
> * Extract variant of the easy parts of Proposal 199, so that pluggable
transports can also act as bridge managers. The parts I propose to build
are:
> * When being launched, a managed proxy can find out a tor controller
port, along with a password or cookie location to use to authenticate to
Tor. An external proxy can get this information too. Getting this
information means that you're acting as a bridge manager.
> * After making a controller connection to Tor, the bridge managers
can use SETCONF to tell Tor about bridge information.
> * Change the semantics of setting "UseBridges 1" when no bridges are
configured. Right now, it's an error. I propose that instead it have the
same effect as
> * Add a new `__Bridge` configuration option. It will have the same
effect as Bridge, but (because it starts with `__`) its values won't be
saved by a SAVECONF command.
> * Add a new ADDCONF / DELCONF command to help maintain the Bridges and
`__Bridges` configuration options. It will only operate on a linelist.
DELCONF will only remove lines when they're provided verbatim.
> * Clarify that it's okay to be a proxy that only supports SOCKS4a, so
that nobody goes out of their way to build SOCKS5 support when they don't
need to.
> * Add a new SOCKS reply code meaning "proxy not ready yet; try later."
> * Let's add a weight parameter to bridges.
What you describe sounds like it will work for flash proxy.
I guess there is a tension with #5018--ideally we want the `flashproxy-
client` transport plugin to start without having to configure any false
bridges. We currently use the "fake" address 0.0.1.0:1, but it's not for
the sake of getting the transport to start up--it's because we don't know
any real bridge addresses at startup time.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7153#comment:17>
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