[tor-bugs] #9022 [Pluggable transport]: Create an XMPP pluggable transport

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Jul 8 15:26:35 UTC 2013


#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:89 asn]:
 > Replying to [comment:79 feynman]:
 > > Replying to [comment:71 asn]:
 > > > Also, do you know what is this error:
 > > > {{{
 > > > WARNING:root:<message xmlns="jabber:client"
 to="blabla at gmail.com/DDA289DC" type="error"
 from="wowowowow at gmail.com"><connect
 xmlns="hexchat:connect"><local_ip>127.0.0.1</local_ip><local_port>60776</local_port><remote_ip>32.1.35.12</remote_ip><remote_port>6061</remote_port><aliases>blabla at gmail.com/DDA289DC</aliases></connect><error
 code="503" type="cancel"><service-unavailable
 xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /></error></message>
 > > > }}}
 > > >
 > > > It appeared on my client-side hexchat. On the client-side I used
 blabla at gmail.com, and on the server-side I used wowowowow at gmail.com. I
 seem to remember you talking about service-unavailable errors.
 > >
 > > I just realized you set up your client to initiate connections to a
 gmail account. That will not work unless the client is on the servers's
 contact list. You can still use gmail, just not for initiating
 connections. You need to have your client run like this:
 > >
 >
 > Ugh, I see.
 >
 > Hm, what do you think is going to be the workflow of users who need to
 get an XMPP account to use with hexchat? If our server-side hexchat bot is
 a @gmail.com JID, how are users going to create non-gmail JIDs? And how do
 they connect with them to Gtalk's servers?
 >

 The server-side hexchat bot can have one or more @gmail.com JIDs, but it
 needs to have at least one that is not gmail. The clients can then
 initiate connections to the non-gmail account with any type of account
 they like (gmail or not). When the server replies, it will send a subset
 of all the JIDs it has logged in with. The client can then send data
 and/or disconnect requests to any of these JIDs.

 The server keeps track of which JIDs it sent for which connection, and
 only sends messages from one of the JIDs it sent during the connection
 phase.

 Keep in mind that the client also sends a list of JIDs during the
 connection phase and keeps track of them in the same way the server does.

 Here is how it works:

 1. Client sends connection request with a subset of all the JIDs it is
 using. Call this set "client JIDs".

 2. Server sends a connect_ack. If the connection was successful, this
 includes a subset of all the JIDs it is using. Call this set "server
 JIDs".

 3. When the client wants to send data, it sends a message from an element
 of "client JIDs" to an element of "server JIDs". When the server wants to
 send data, it sends a message from an element of "server JIDs" to an
 element of "client JIDs".

 Clients and servers can send messages to arbitrary JIDs after the
 connection is established because "client JIDs" and "server JIDs" are full
 JIDs that include resources. Full JIDs are of the form
 user at server/resource. Resources are sometimes assigned randomly (even if
 you request one)--as is the case for gmail.

 You cannot send an IQ stanza to a JID of the form user at server (i.e.
 without the resource) but you can send a message stanza to a JID without a
 resource. That is how clients initiate connections--at least the first
 time. After it gets a response, it adds the responding JID to a dict that
 keeps track of possible full JIDs to send connection requests to. From
 then on, it sends connection requests via IQ--at least until it gets an
 error. When it gets an error, it deletes the JID from its dict.

 This all works fine for everything but gmail. You can only send messages
 to gmail JIDs without resources if you are on that JID's contact list. I
 found no way around that problem, so you cannot initiate connections to
 gmail accounts. Period.

 > Also, if users want to have N aliases (to increase their speed), they
 also need to create N JIDs, right?

 Sort of. I found you can log into many accounts about 20 times from the
 same IP address before it refuses the connection. Here is a list of
 servers that let you login at least 100 times before refusing the
 connection:

 https://trac.torproject.org/projects/tor/ticket/9022?replyto=89#comment:84

 Some of those servers are very slow, but the jabber.* ones seem fine.

 You can get away with logging into the same account multiple times because
 chat servers give you a random resource by default--thus giving you a
 unique full JID of the form user at server/resource--which is what you are
 going to send data to anyway.

 Note that messages sent to a JID without a resource will be sent to all
 JIDs of that form. So a message sent to user at server will go to everyone
 logged into user at server--regardless of their resource. I have already
 implemented code that guarantees only one of those resources will actually
 execute the connection process.

 You can specify the number of times to login to each JID with the
 --num_logins option. The default is 1.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9022#comment:90>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list