[tor-dev] XMPP Pluggable Transport

Sat Jun 22 18:17:59 UTC 2013

I have been working on creating an XMPP pluggable transport for Tor  
for a couple of weeks now, and someone suggested I send an email to  
this mailing list for suggestions.

At this point, my priorities are ordered as follows:
1. Speed--I can watch low quality youtube videos on a bad internet  
connection, but there is a lot of down time while it buffers (not an  
unbearable amount of time, but enough to be annoying). This has been a  
big problem for a while, and I could really use some suggestions on  
how to speed it up.

2. Full GTalk compatibility. It seems you need to be on a recipient's  
contact list to send a message to them (at least without supplying a  
resource). However, I currently use messages to send connection  
requests to JIDs with unknown resources.  Then when they reply, their  
resource is saved in a table. This technique works fine for everything  
but GTalk, which of course is by far the fastest of the chat servers I  
have tested.

3. Error handling--I need to make sure I take everything into account.  
I do not have anything that can reestablish connections if one  
computer disconnects from the chat server and reconnects. In fact, if  
it acquires new resources (which is what happens on GTalk), the other  
computers will be stuck sending messages to a JID with the wrong  
resource. I am pretty sure I can come up with some ways of dealing  
with this. Right now, looking for potential problems is just as  
important as pointing out solutions to more obvious ones.

4. Security. I know security is important, but the nature of the  
program just does not seem to admit many security threats. There are  
really just three that I can see:
- The server can be told to connect to any ip:port by a client.
- The server and client exchange their Python interpreter's  
sys.maxsize values (which could lead to profiling a computer's OS).  
The former can be fixed with a whiltelist and the latter is not even  
necessary (I just have not gotten around to tweaking that out of the  
protocol yet).
- DoS. This would be relatively easy to take into account by limiting  
the number of connections a bot is willing to accept. Then the chat  
server itself will limit the amount of data sent from any one JID (for  
better or worse).

If you think you are able/willing to help, read on for a summery of  
the concept and protocol below. Even if you are not well versed in  
XMPP protocols (I myself am learning as I go), just helping to test  
the program would be a big help.

Thanks,
Alex Eftimiades

A brief summery of how the program works can be found here:
https://trac.torproject.org/projects/tor/ticket/9022#comment:42
, and is reproduced below:
---------------------------------------------<Summery of  
concept 
 > 
---------------------------------------------------------------------------------------------------
  When using hexchat, the data is sent to a local TCP socket running  
hexchat (call it hexchat1). Hexchat1 then reads the data (thereby  
stripping it of its TCP header) and passes it over a chat server to  
another hexchat program (call it hexchat2) that sends the data to the  
appropriate ip:port (giving it a new TCP header in the process).
The client thinks it is sending the data to hexchat1, and the server  
thinks it is receiving data from hexchat2, but the data itself is  
never changed. It might be broken into smaller chunks or combined into  
bigger chunks, and it might be delivered at unpredictable rates, but  
it is never altered.

---------------------------------------------</Summery of  
concept 
 > 
---------------------------------------------------------------------------------------------------

A more detailed overview of the protocol can be found in the protocol- 
spec here, though I will summarize it:

---------------------------------------------<Summery of  
protocol 
 > 
---------------------------------------------------------------------------------------------------

When the program is started, it is told what JID(s) to use to connect  
to a chat server, and possibly the following optional parameters:

1. An ip:port to listen on.

2. A JID.  Connection requests will be sent to this JID when a  
connection is is made to the ip:port specified in (1).

3. Another ip:port. This is the ip:port the bot connected from the JID  
in (2) should connect to. Note that any bot can connect to any ip:port  
that client asks for. This could be a 127.0.0.1 address, or a remote  
address (but will probably be the former). I plan to add a feature in  
which you can provide a list of acceptable ip:ports to connect to and  
refuse to connect to anything else (for security). However, that is  
not a priority at the moment.

When a connection is made, the server and client exchange all JIDs  
they are using to connect to the chat server so they can each rotate  
through JIDs to send messages from and JIDs to send messages to. With  
the exception of initial connections, all messages are sent as IQ  
stanzas.

When data is sent, it is base 64 encoded and sent with an ID number  
that is incremented each time a message is sent.

When data is received, the id is checked against the id of the last  
message that resulted in writing data to a socket. The difference  
between these two ids is used as an index in a buffer. Then, messages  
are read from the buffer and sent to the appropriate socket.

When a socket closes, a disconnect message is sent. Like when sending  
messages, an id stanza is included.

When a disconnect message is received, the bot checks if there are any  
entries in the appropriate socket's message buffer. If not, it closes  
the socket and deletes it from the routing table. If there are  
messages in the buffer, the disconnect message is added to the buffer  
at the appropriate index as a string "disconnect" as though it were  
normal data. When a "disconnect" string is found in the buffer, the  
socket is closed and deleted from the bot's routing table.

---------------------------------------------</Summery of  
protocol 
 > 
---------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130622/8d17cf99/attachment.html>