jdev - 2024-08-07

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.

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.

(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)

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

FunXMPP but a negotiated standard layer

> 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. ↺

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

EXI does a lot more than FunXMPP

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

it can achieve more than that certainly

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

> 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. ✏ ↺

Link Mauve, fair point.

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 ✏

Is there any client using it?

I do not know