I've been thinking about the hashes in XEP-0065 (SOCKS5 Bytestreams), which folks have commented on before (e.g., they don't work in MUC rooms). For those who forget, the hash is formed as follows:
SHA-1(SessionID + Initiator JID + Target JID) The idea here was that the proxy could check the 'from' address on the IQ stanzas it receives as a way of correlating a bytestreaming session with a particular JID pair (initiator and target). However, the proxy never receives an IQ from the target -- all of its communication with the target happens via TCP / SOCKS5, not XMPP. So we don't necessarily have the security properties we thought we had. To be fair, XEP-0065 says: 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. So it doesn't really promise that the hash prevents someone from masquerading as the target. The initiator's activate request (sent to the proxy) does include the target JID, but that information is meaningless from a security perspective because the proxy has no way of checking the target JID. Thus it seems to me that the best we have is a ticket that's tied to the initiator. This is better than nothing, I suppose, but it doesn't require the DST.ADDR to include the target JID. As to the MUC use case (the initiator doesn't know the target's real JID), removing the target JID from the hash would help with one part of the problem. However, the target doesn't necesarily know the initiator's real JID, either, so it can't construct the proper hash. One approach would be for the initiator and target to "decloak" (share real JIDs) before / while setting up the file transfer. If we remove the target JID from the equation then only the initiator would need to do that. Another approach would be to make DST.ADDR a pure ticket / bearer token that's not tied to the JIDs in use. If you don't want someone else to use the ticket, encrypt it in transit. (That doesn't help if you are doing XTLS over SOCKS5 in the first place for encryption -- chicken and egg.) Yet another approach would be for the MUC room itself to function as a bytestreams proxy -- it knows the room JIDs so those could be used when sending the activate request. Or a bot in the room could act as a broker for the bytestreaming session establishment. I don't have the answer, but at least wanted to start a discussion about this because it's an open issue in XEP-0065 and our file transfer "stack" more generally. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
