[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport
#9022: Create an XMPP pluggable transport
---------------------------------+------------------------------------------
Reporter: asn | Owner: feynman
Type: task | Status: accepted
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: | Parent:
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by feynman):
Replying to [comment:55 asn]:
> Replying to [comment:54 feynman]:
> > I just tried hexchat with tor and I can safely report success in
getting basic webpages to load (very slowly), and even watching a video
(with a lot of buffering). I am using the following configuration:
> >
>
> Nice! Do you see a big difference (speed-wise) from normal Tor browsing?
>
> > laptop browser=>laptop hexchat=>chat server=>desktop hexchat=>desktop
tor=>desktop hexchat=>chat server=>laptop hexchat=>bridge
> >
> > ...and I have the wireshark logs to prove it.
> >
> > Keep in mind that this test should be about twice as slow as a normal
hexchat connection since I am crossing the chat server twice as many times
as I would in a normal pluggable transport connection.
> >
> > I am also using three gmail accounts per computer. Perhaps a real
proxy server would/should use even more.
> >
> > I also have some basic error handling if one computer is disconnected
from one or more of its accounts.
> >
> > I would appear that the only thing left to do is to get this to work
with GTalk so that anyone can initiate a connect to anyone--regardless of
whether the client is on the server's contact list. That, and to limit the
ip:ports a server can connect to with a whitelist (but the latter should
be quite easy).
>
> Yeah. Are you sure you want to take the whitelist approach? Having the
server forward all traffic to a single address might be more convenient.
>
I would strongly prefer using a white list approach to maximize
versatility. You never know when you might want a server to be able to
connect to different IPs.
Maybe one IP is down, and you want it to be able to connect to something
else. If the hexchat server is only able to connect to one IP, you would
have to restart the server to start working with a different IP. On the
other hand, if it can connect to several IPs, then the client can run
several instances of hexchat--each listening on a different local ip:port
and configured to ask the server to connect to a different bridge. Then
Tor can chose between several local IPs as though they were different
bridges.
> Specifically, we will need hexchat to have a command-line interface
similar to the one described in comment:18, if we want to deploy this
without the managed-proxy interface.
Just look at the readme file on the git repository. I have been using a
command line interface the whole time. Adding a whitelist of servers
should not be hard.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:57>
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