LWN.net Logo

Different compression scheme

Different compression scheme

Posted Sep 14, 2012 13:24 UTC (Fri) by epa (subscriber, #39769)
Parent article: CRIME Attack Uses Compression Ratio of TLS Requests as Side Channel to Hijack Secure Sessions (threatpost)

Any sliding window compression scheme - indeed, any compression scheme at all which adapts to the input data - has this problem that if you can control what comes before or after the secret text, you can infer things about the secret text from the length of the resulting message.

For applications like SSL headers where the content must be kept secret but saving bandwidth is still important, a simple Huffman code with fixed weights could be used instead. In other words somebody analyses typical traffic to find the frequency of each byte value, and these frequencies are then hardcoded in the compressor and decompressor. This would still save a lot of bandwidth but would not have this class of vulnerability. It also requires less memory for compression and decompression, which I guess might still matter if you have thousands of incoming connections.


(Log in to post comments)

Different compression scheme

Posted Sep 20, 2012 5:45 UTC (Thu) by alonz (subscriber, #815) [Link]

Another option is to reset the compression state between the headers and payload (I know many compression schemes have a special control code to do this — unfortunately I don't know if SSL/TLS compression does).

Different compression scheme

Posted Sep 20, 2012 11:43 UTC (Thu) by epa (subscriber, #39769) [Link]

Here I think the attacker can add things to the headers, such as cookies or the exact path being requested. So you would need to reset the compression state between one header line and the next.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds