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.
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.