I am writing full-stack server side software and I have been researching CRIME attacks and it's relation to SPDY header compression as I am implementing the server side codecs for it at the moment.
The conclusion seems to be that compression and encryption should not mix.
Having looked into both CRIME and BREACH. I am wondering if the following methods are viable to disable ALL types of "guess work" attacks in compressed and encrypted data streams (on the server side)
1) Rate-limiting - as suggested on BREACH's site. Any clients bombarding a server with over 100 request per second is bound to be malicious when pages on your sites only serves a maximum of X (single/low double digit) resources per request.
2) Dynamic data - both CRIME and BREACH (and their derivative) seems to rely on repeated probing and assumes the position of data does not change. What if both HTTP headers and body are shuffled per response by the server? Combined with small variable length random dummy data injected in both body and header? Can this effectively disable all such attacks with CRIME and BREACH's characteristics?
Thanks for your time.
EDIT 1: I should point out that I am specifically referring to data streams within the HTTP protocol (i.e. HTTP compression and SPDY header compression) and not SSL/TLS compression.
EDIT 2: The attack mitigation solution I am trying to achieve/suggest is on all possible "compression + encryption" info leak attacks, CRIME and BREACH may only be recent examples.
EDIT 3: The BREACH presentation seems to suggest variable length padding is not a valid mitigation. However it doesn't seem to consider the combination of a randomised message structure + randomised padding can create an (in theory) infinite combination of unreliable outputs thereby removing any correlation between the compressed and encrypted output length to the actual message meaning.