jdev - 2024-08-07


  1. dwd

    I'd still like to see a proof of concept of the compression oracle. My view is that while it exists theoretically, it's still too complex to yield useful data. The ingredients are that an attacker can cause an entity to send some traffic containing specific data over a specific stream such that it is sent within the compression window, and then measure the packet size to determine if that data has been compressed (by reference to the data having been sent previously within the window). In the HTTP world, the concern was an attacker looking for specific data, like cookies, which were sent near the top of every request, so by crafting a special URL or something you can get the cookie and your attack data within the window quite easily. I can see ways of causing a client, say, to send data under the attacker's control (ping them from a resource containing your data, for example), but not a way to ensure that's within the compression window of anything useful.

  2. dwd

    And note this still requires an attacker to monitor packet sizes of the target, so an on-path attacker, which is hard as it is, and it's a targeted attack not a dragnet, so we're assuming that an attacker is going to target you, specifically, to find out if you're sending a particular short string in your stream. This is all adding up to being a very expensive, very specific attack, and I'm not convinced it's even realistic.

  3. dwd

    (Although as Zash says, compression context cost in terms of memory is shocking on the server, so there's very good reasons not to enable compression in many cases anyway - maybe we should go for the bizarro magic token expansion of WhatsApp)

  4. Schimon

    Which descriptiive subtitle would be nicerfor project Blasta? (1) PubSub Bookmarks (2) Jabber Bookmarks

  5. Zash

    FunXMPP but a negotiated standard layer

  6. moparisthebest

    > Which descriptiive subtitle would be nicerfor project Blasta? > (1) PubSub Bookmarks > (2) Jabber Bookmarks Schimon: I'd just like to interject for a moment. What you're refering to as Jabber, is in fact, XMPP, or as I've recently taken to calling it, XMPP not Jabber. Jabber is not an internet protocol unto itself, but rather another proprietary product owned by Cisco. XMPP instead is a fully functioning free protocol made useful by standardization and extensibility.

    😂 1
  7. Link Mauve

    dwd, from what I’ve understood of it, EXI is pretty close to FunXMPP, except it is unobtainium.

  8. jonas’

    EXI does a lot more than FunXMPP

  9. Link Mauve

    Sure, but it can be configured to achieve FunXMPP levels of compression.

  10. jonas’

    it can achieve more than that certainly

  11. Link Mauve

    Did anyone redo any RE of their protocol nowadays, to see how FunXMPP has evolved?

  12. Link Mauve

    Did anyone redo any RE of their protocol recently, to see how FunXMPP has evolved?

  13. Schimon

    > Schimon: I'd just like to interject for a moment. What you're refering to as Jabber, is in fact, XMPP, or as I've recently taken to calling it, XMPP not Jabber. Jabber is not an internet protocol unto itself, but rather another proprietary product owned by Cisco. XMPP instead is a fully functioning free protocol made useful by standardization and extensibility. Perhaps. Yet, the word Jabber has a meaning: chatter, prattle; mumble, babble, speak incoherently.

  14. Schimon

    > Schimon: I'd just like to interject for a moment. What you're refering to as Jabber, is in fact, XMPP, or as I've recently taken to calling it, XMPP not Jabber. Jabber is not an internet protocol unto itself, but rather another proprietary product owned by Cisco. XMPP instead is a fully functioning free protocol made useful by standardization and extensibility. moparisthebest. Perhaps. Yet, the word Jabber has a meaning: chatter, prattle; mumble, babble, speak incoherently.

  15. jonas’

    Link Mauve, fair point.

  16. Guus

    For all of the recurring EXI talk recently: did anyone try the Openfire implementation? I'd love to get some interop feedback on it. https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://discourse.igniterealtime.org/t/developing-openfire-efficient-xml-interchange-exi-functionality/92663

  17. Guus

    For all of the recurring EXI talk recently: did anyone try the Openfire implementation? I'd love to get some interop feedback on it. https://discourse.igniterealtime.org/t/developing-openfire-efficient-xml-interchange-exi-functionality/92663

  18. Link Mauve

    Is there any client using it?

  19. Guus

    I do not know