Hello, I'm currently implementing SOCKS5 support (XEP-0065) [1] in telepathy-gabble and I'm facing a number of pretty annoying issues.
First, the XEP is unclear about JID's usage when trying to establish a bytestream with a muc contact (for example to send him a file). During the SOCKS5 negotiation, the target has to send a CONNECT command to the streamhost. This command has to contain a hash calculated as: SHA-1(SID + Target JID + Initiator JID) If a proxy is involved, the initiator has to connect to the streamhost and sends a CONNECT command too containing the same hash. But which JID's should be used? The global ones ([email protected]/foo and [email protected]/bar) or the muc specific ones ([email protected]/initiator and [email protected]/target) ? If we want to be able to establish bytestreams in anonymous muc we have to use muc specific JID's. (Btw, Pidgin confuses itself because of this and can't send files to muc contacts [2]). So let's use muc JID's. This work fine when establishing bytestreams directly between the 2 peers (the initiator is the streamhost) but break horribly when a proxy is involved. As said in the XEP, the initiator and the target have both to connect to the proxy and request a connection (using the same hash as defined above). Once the Initiator got his CONNECT reply, he has to send an IQ to the proxy in order to activate the bytestream. The XEP says (Section 4.9): """" In order for the bytestream to be used, it MUST first be activated by the StreamHost. [...] This is done by sending an IQ-set to the Proxy, including an <activate/> element whose XML character data specifies the full JID of the Target. Using this information, with the SID and from address on the packet, the Proxy is able to activate the stream by hashing the SID + Initiator JID + Target JID. This provides a reasonable level of trust that the activation request came from the Initiator. """ But in this case the from attribute of the IQ is NOT the JID of the initiator as we used the MUC JID's when sending the CONNECT cmd! So, the proxy will use as hash: SHA-1 (ID + [email protected]/foo + [email protected]/target) but the target and initiator used this hash during their SOCKS5 negotiation: SHA-1 (ID + [email protected]/initiator + [email protected]/target) As the hashes don't match, the proxy doesn't find the bytestream and reject the activation request. Finally, this revealed another problem in the protocol. Once the target is connected to the proxy and he sent his IQ reply to the initiator (to inform him of the streamhost used), from his pov the bytestream is open. So the target will never know that the activation failed! This is a major issue for us because the target won't fallback to IBB as he'll continue to think that the bytestream was properly open using S5B. To summarize, we have the following issues with current XEP: A) The XEP doesn't specify which JID's have to be used when negotiating a bytestream between muc contacts. B) If we use muc JID's (which is the sane thing to do), the proxy rejects the bytestream activation. C) When activation failed (or if the initiator can't connect to the proxy for any reason), the initiator is never informed of the failure and think the bytestream is open. These are my suggestions to fix these issues: A) We should always MUC JID's so we don't restrict ourself to non-anonymous muc. B) The activation IQ should contain the initiator JID instead of assuming it from the "from" attribute of the IQ. C) We should add an extra IQ round trip between the initiator and the target. Once the initiator got the activation IQ reply, he sends an IQ to the initiator to inform him of the success (or failure) of the operation. The target shouldn't consider the bytestream as open while he don't receive this IQ. This is a *very* serious issue for us as we use bytestreams (S5B and IBB) not only for file transfer but also for tubes (home made extension to establish a bytestream for external applications). OLPC/Sugar uses muc tubes extensively so having this working properly is crucial for us. Thanks. G. [1] http://xmpp.org/extensions/xep-0065.html [2] http://developer.pidgin.im/ticket/8524
