On 10/9/14, 7:59 AM, Thijs Alkemade wrote:
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.
Could you explain that a bit more? For example, are you talking about
compressing two stanzas and sending them in the same TCP packet?
2. Or that we apply framing outside of compression (which I expect to be
another can of worms).
Yes, I'd expect so. I recall debates about framing (or the lack thereof)
for XMPP on this very list from over 10 years ago. ;-)
a> zlib has a header bit that indicates whether a block is the last
block in a
stream, but again, that might be zlib-specific.
Would it be worthwhile to investigate what the various compression
algorithms support here?
Peter
--
Peter Saint-Andre
https://andyet.com/
