[Standards] compression attacks
thijs at xnyhps.nl
Mon Feb 17 13:44:23 UTC 2014
On 17 feb. 2014, at 14:29, Winfried Tilanus <winfried at tilanus.com> wrote:
> Signed PGP part
> On 13-02-14 13:19, Thijs Alkemade wrote:
> > On 13 feb. 2014, at 01:04, Peter Saint-Andre <stpeter at stpeter.im>
> > wrote:
> >> While working on draft-sheffer-uta-tls-attacks with Yaron
> >> Sheffer this week, he pointed out to me that the TIME and BREACH
> >> attacks might apply to application-layer compression technologies
> >> such as XEP-0138 for XMPP. I haven't looked into that in detail
> >> yet, but I figured I'd raise the issue here for discussion.
> XEP-0138's context is to provide compression when TLS is not
> available. So it should not be used together with TLS, but the
> security considerations cover the case where both are used. Maybe
> better adjust these.
Prosody recommends disabling TLS compression and enabling XMPP compression
instead, citing high memory usage by OpenSSL for the latter. The intended goal
might have been to allow for compression without TLS, but that's not how it's
used in practice.
TLS compression is also more vulnerable to compression attacks as it covers
the SASL exchange too.
> > Depends on what data you consider secret.
> > Passwords shouldn't be in the compressed stream, per XEP-0170.
> > Other highly sensitive data can be your contact list and the
> > contents of your messages. Both of these an attacker should not be
> > able to trigger retransmissions of, which complicates attacking
> > them.
> > But it's likely the attacker will be able to extract information
> > like "is juliet at example.lit on your roster?", "did you receive a
> > message from juliet at example.lit in the past 32 kB?" (the zlib
> > window size) or "did you receive a message that included the phrase
> > 'thermonuclear war' in the last 32 kB?".
> Thijs, can you explain this a bit more? As far as I understand these
> attacks, they work when both a secret and data supplied by the
> attacker are in the same compression context. That has to be the same
> 32 kB compression window (in the case of zlib). I don't see how the
> attacker can inject data into that, we don't have CSRF issues in XMPP.
> Or it has to be for contexts like the IOT, where sensors can be
> manipulated so you can test if the sensor has been sending the same
> value just before.
I'm making the following assumptions:
1) The attacker is able to route XMPP packets to the target (by a presence
subscription or by knowing their full JID).
2) The attacker is able to observe the length of the packets between the
server and the target's client.
Sure, if you're only considering scenarios where TLS isn't used then these
assumptions make no sense, because any MitM will have full read/write access
to the stream.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards