On 1 feb. 2014, at 12:54, Alexander Holler <[email protected]> wrote:
> Am 01.02.2014 12:46, schrieb Thijs Alkemade: >> >> On 1 feb. 2014, at 10:47, Alexander Holler <[email protected]> wrote: >> >>> Am 31.01.2014 22:51, schrieb Thijs Alkemade: >>> >>>> These use an incrementing counter to generate ids, starting from 0. This >>>> means >>>> that, for example, roster retrieval always gets the same id and could be >>>> spoofed by a fast enough attacker: >>> >>> Could you elaborate how that attacker does send those spoofed stanzas? >> >> Okay, "fast enough" isn't really accurate, you need to cheat to be faster >> than someone's own server. >> >> Suppose I want to target someone and I know the server they use, the account >> there, the fixed resource they have set and that I have control over the >> network my target is using. >> >> I can see there's an outgoing connection to an XMPP server, but it's using >> TLS >> so I can't directly manipulate it. However, the initial packets on a stream >> usually have a set ordering, depending on the client. If I know the roster >> retrieval is always the 3rd iq packet, and always the 7th TLS packet, then I >> can delay the 7th TLS packet while I send an new packet to the target's >> server: > > Hmm, How you do replace a packet in a TLS stream? > > I don't consider the id (or even the resource name as mentioned in another > mail) as part of the security concept of XMPP. > > If you are able to inject or replace packets in a stream, almost everything > can be done. > > Maybe I miss something important here. I don’t replace the packet, try to read what I write. I only *delay* one TLS packet to give me enough time to send a reply before the query arrives at the server. Thijs
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
