Re: [Standards] compression attacks
On 17 feb. 2014, at 14:29, Winfried Tilanus wrote: > Signed PGP part > On 13-02-14 13:19, Thijs Alkemade wrote: > > On 13 feb. 2014, at 01:04, Peter Saint-Andre > > 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 jul...@example.lit on your roster?", "did you receive a > > message from jul...@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. Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] compression attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 17-02-14 14:29, Winfried Tilanus wrote: Hi, > 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. Brain-fart, of course this can be done by sending messages to the victim from an other JID. So yes, this can be a problem. Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTAhFNAAoJEHZ7UH0X6Ldc+dgP/R7st7bQCZ1/GsE8d+Ay5t00 NJww1gWnhGWZnepZN6baM3QvZ2QI3Hiw7hGoexscD52YLtY3aWZQT5X3W5/9NlD1 d81BY/3cr2uHCKwJ2bnvlqxeoTBHbFHUK4xtbAiqs1ftJEFzKP01mCizPNzUDdXm x2s0mKBg3K8UDx7nuqPQdzFlVrMGvI7KteRx73ct+N1IIsGeyrjOBCerxmMaIpkl GsbVpL6GghLDwxEVH7RqSi0glgfzH0B9AptkJ/tPfwQw29GNKYiUEJIvGG6utPF3 Rz4qJ3tsZYm3p3jdpTu6x8nQIQgsufZP+dI7vfSHJbbrrP6TmmL2Ruh+9thzjKgv +AkZqr9rrxHXqFQMJ2nQKz8oB+6GZ/iam1ngXkgplxF2toWRWYSYwq/Ebo4lZ4P9 wS8APhpvcTcG9TlirCTBCF9ftvO1qZmn6X/677CdfxoFdTu6X1oJ1JEsCm+MqM42 CEByWiErQWnVYqAY1ZHnVufPsYG+znFCNby6XUW0isaE6Hx0g1ma21DP+VeF17Gy P1GJsm52eSbY8crGVAaDG7cpdel4E/vl77fUhUrM2jsLETWyXNagXPW61qDLSsPx R6pswGQ7I1BBaoxkjqm+//o/KTw/sA+A+dSxvJ2n3TTZN9qE6wYl6Rq8njJMfn1/ 1lPO52kZhWBQN2HnLZu9 =T4up -END PGP SIGNATURE-
Re: [Standards] compression attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 13-02-14 13:19, Thijs Alkemade wrote: > On 13 feb. 2014, at 01:04, Peter Saint-Andre > 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. > 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 jul...@example.lit on your roster?", "did you receive a > message from jul...@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. Winfried -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTAg6TAAoJEHZ7UH0X6LdcwrAP/1YB1H91bw6RzIrwMXKLCDOl 0SdZE9dfA5WBpoWmd/prclOiTKTIaIQZxVnZZBJhMtySuKePMIrQ11Md+wkcQtYe IMRsOqmSpBkN07BPJdZmEPMGgpiqMHGzhGgxskyakZXETHvv01bx6QFFuZtpnevR bg26eiiSHNuTXpPDZyZSK/OhmeP2eitRawi8edqlH5hjpsn9D0gWrQQb8H1mrzlJ FaM2diFFalAg5vJPOIEDHQnCtcMO5Xb2czB04jhsm/XlC1xQzgQDe1PYooYnq4AQ y5JzpTOreI9pDv3RLZb3mLSp7WaGIw/dCjp9Qtb4KZlUuD4WXaJVdsG9kxH0txgr VDQVBAVe+t9ByWTDqx7HqkltI6v+s0WLTVEy8S7FpswMSSj8vWmUiTbC4kpO04iS IA0UJU6cjkSrCbib19M40OB13xdZKMXybObFttRLKt/OARbcFNowWB6S66rEGECA eb2yOOKV0ir+VGw5aePCJ5LxbLJ2NgsrJShqOTjgXvi9wOLcEZm9jD+jJivLfd5Q czEuVuJTqLmqSQSIRI33tv72KMY8TcNLcXIsN79hncLbysgo6IfpyicXCgZBXLPl AtEAdDMJL2PDwxBZUG/dI3oJ2TnzJujrOq4ZdGOcojQtP1+sCnC88+5eHVz/HDf1 xeleqqxxbBZfQnL6PQr/ =DUFi -END PGP SIGNATURE-
Re: [Standards] compression attacks
On 13 feb. 2014, at 01:04, Peter Saint-Andre 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. 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 jul...@example.lit on your roster?", "did you receive a message from jul...@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 signature.asc Description: Message signed with OpenPGP using GPGMail
[Standards] compression attacks
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. Peter -- Peter Saint-Andre https://stpeter.im/
