> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jeffrey Walton > Sent: Tuesday, April 07, 2015 18:37 > To: OpenSSL Users List > Subject: Re: [openssl-users] removing compression? > > It seems to me the trick to avoid CRMIE-like attacks is to make sure > the compression is semantically secure. In the case of CRIME, > information should not be gained across different messages (in this > case, each message alone was secure - it was the different messages > over time that got folks in trouble). > > But I'm not sure about other attacks on the compression layer. Compression will always be a side channel that leaks information if the size of the message changes in a way that has a predictable relationship to the input. As with any side channel, the only real options are denying the attacker access to it (infeasible in the case of communications compression) or whitening it by adding noise. The random-flush technique Jakob discussed yesterday is one way to add noise; random-length incompressible padding is another. The CRIME and BREACH attacks are just two (more) instances of the very general category of side-channel attacks on ciphertext that represents largely-predictable parts of plaintext. Defense amounts to making the plaintext less predictable or confusing the relationship between the two. For that reason, if I had an application running under a threat model that included attackers mounting passive or active attacks on the compression side channel, I'd want to disable any automatic compression mechanism, personally. But I suspect many OpenSSL applications don't include that in their threat model, because their traffic doesn't provide suitable opportunities, or it's not of sufficient value, or the users just don't care. So I have no strong feelings either way about this feature in OpenSSL. -- Michael Wojcik Technology Specialist, Micro Focus This message has been scanned for malware by Websense. www.websense.com
