<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 9, 2015 at 1:51 PM, Christoph Anton Mitterer <span dir="ltr"><<a href="mailto:calestyo@scientia.net" target="_blank">calestyo@scientia.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, 2015-01-09 at 13:22 +0100, Stephan Neuhaus wrote:<br>
> I have come across the recommendation to "compress before you encrypt",<br>
> on the grounds that this makes plaintext recognition through frequency<br>
> analysis much harder.<br>
</span>Compression before encryption may be used as an oracle when plain text<br>
injection is possible...<br>
See CRIME/BREACH attacks and the principle behind them.<br></blockquote><div><br></div><div>I think it is a bad idea to take too much from HTTPS experience. The problem is much narrower and much more general.</div><div><br></div><div>First the HTTPS attack: if you put active code into a system and you allow someone to manipulate one part of a message, this may allow them to deduce other parts of the message. Well we could blame the compression but the real problem here is the active code and the use of bearer tokens for authentication: Get rid of one or the other or expect the pain to recur.</div><div><br></div><div>If you are using active code then you should assume that EVERY part of EVERY message that the active code can initiate is disclosed to the code. </div><div><br></div><div>But turning off compression is a much easier fix than changing the way cookies work. So we take the easy route as always and will wonder why it breaks again.</div><div> </div></div><br></div></div>