Le jeudi 05 mars 2009 à 08:39 -0800, Justin Karneges a écrit :
> On Thursday 05 March 2009 05:45:09 Guillaume Desmottes wrote:
> > 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).
>
> Yes, S5B is totally busted with MUC JIDs. We mostly brushed this off, saying
> that you have to use real JIDs. I think it is not unreasonable to require
> using real JIDs for a P2P connection, if only we had a better way of
> communicating the JIDs (e.g. trading them in the file transfer exchange,
> rather than requiring a non-anonymous MUC).
> > 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.
>
> You mean the target is never informed.
Right; sorry for the confusion.
> > A) We should always MUC JID's so we don't restrict ourself to
> > non-anonymous muc.
>
> Do we have to require their use? Is there a harm in using real JIDs even if
> both peers are in a MUC? I don't think this needs to be specified.
>
> > B) The activation IQ should contain the initiator JID instead of
> > assuming it from the "from" attribute of the IQ.
>
> This may be fine, but, does it open up any security issues? People hijacking
> proxy connections by spoofing initiator JIDs?
I considered different solutions and tried to implement some. These are
my current conclusion.
Use the real jid from the muc presence (when the muc is not anonyme)
doesn't really work because it doesn't contain the resource of the peer.
So the Target will send a hash which has been computed without the
resource of the initiator which won't match with the one computed by the
initiator (which include the resource).
We could say that in the muc case the resource doesn't have to be in the
hash but that would be very ugly and not coherent with the "normal"
case.
The XEP says that the JID used in the hash have be the same used during
the IQ exchange; I think that's a sane requirement.
So, I see 2 solutions for this problem.
1. Use the MUC JID in the hash
------------------------------
The hash is computed using the initiator and target muc JID. A new
attribute is added to the activation stanza and the proxy use this
attribute as initiator jid instead of infering it from the IQ 'from'
attribute.
Proxy have to advertise if they support this new extension. Target
should ignore old proxies (not send them as streamhost) when negotiating
a bytestream with a muc contact.
Pro:
- Seems the more natural solution as we respect the "use IQ JID"
requirement.
- No real JID leaked in anonymous muc
Con:
- Proxy has to be modified.
- Can't use old proxy with muc contacts
- The Proxy can't check that the jid passed as attribute in the
activation stanza actually belongs to sender of the IQ. Maybe a security
issue?
2. Add our real JID in SOCKS5 IQ's
----------------------------------
Initiator and target set their real jid (with the resource) in the
SOCKS5 IQ's (the offer and the reply). They use these JID's when
computing the hash.
Pro:
- Work with existing proxy
Con:
- You leak your real jid when trying to establish a bytestream. This
means that sending a file to a muc contact leaks your real jid to him
and accepting a file from a muc contact leaks your jid to the file
offer.
That's even worst with our muc stream tubes because that means that
offering a muc stream tubes to a muc potentially leak your jid to all
the participants of the muc.
- Break the "use JID from the IQ's" principle
- Initiator is not aware of the target's real jid before he received the
SOCKS5 reply. So, if the target connects directly to him, he can't check
that the hash passed with the CONNECT command is the right one. This is
*very* annoying IMHO.
Personally, I'd vote for 1). Having to change proxies is unfortunate but
that seems to be the price we have to pay for privacy and keeping the
protocol more coherent.
> > 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.
>
> I'd have to think more about this, but maybe it's fine.
C) is an orthogonal problem; let's focus on A and B for now.
G.
