[tor-dev] XMPP Pluggable Transport

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