Hello all, Stream compression is insecure, that was shown with CRIME and BREACH and the situation for XMPP isn't much different [1]. I think we should look at the easiest way to deprecate XEP-0138 and move to something better.
Using a "full flush" (in zlib terms) after every stanza would solve the problem, as I can't find any realistic examples where an attacker could insert their own payload into the same stanza as something secret they want to know. However, clients and servers have no way to negotiate a mode like that, so it's not possible to reject connections that won't do a per-stanza full flush. Reading draft-ietf-hybi-permessage-compression-18, I was happy to see that this could be negotiated in WebSocket extension [2]. From my own (very small scale) tests with raw XMPP XML, it appears that full flushing after every stanza yields about the same compression ratio as compressing each stanza separately. Doing that would have a number of advantages: 1. Not relying on nothing leaking through the "full flush", which may be a concept that other compression algorithms than zlib don't have or don't do securely enough. 2. Practically no memory overhead in the server or client between messages. There's no context to keep around, each new message can be decompressed with a fresh new context. Memory overhead for compression is a real concern for servers: one of the reasons Prosody was pushing for XEP-0138 to replace TLS compression was that it's impossible configure the memory use of TLS compression to sane levels in OpenSSL. However, it also has downsides. It requires either: 1. That the concatenation of two compressed stanzas can be separated unambiguously. 2. Or that we apply framing outside of compression (which I expect to be another can of worms). zlib has a header bit that indicates whether a block is the last block in a stream, but again, that might be zlib-specific. Thoughts? Comments? Best regards, Thijs Alkemade [1] https://blog.thijsalkema.de/blog/2014/08/07/https-attacks-and-xmpp-2-crime-and-breach/ [2] https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-18#section-8.1.1
signature.asc
Description: Message signed with OpenPGP using GPGMail
