On Mon, May 20, 2024 at 11:05 AM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > > So, the data would be compressed first, with framing around that, and > > then transport encryption would happen afterwards. I don't see how > > that would leak your password, but I have a feeling that might be a > > sign that I'm about to learn some unpleasant truths. > > Compression defeats encryption. That's why it's not in TLS anymore. > The thing is compression codecs use data self correlation. And if you mix > secret data with user's data, user might guess how correlated they are.
I'm slow on the draw, but I hacked up a sample client to generate traffic against the compression-enabled server, to try to illustrate. If my client sends an LDAP password of "hello", followed by the query `SELECT 'world'`, as part of the same gzip stream, I get two encrypted packets on the wire: lengths 42 and 49 bytes. If the client instead sends the query `SELECT 'hello'`, I get lengths 42 and 46. We lost three bytes, and there's only been one packet on the stream before the query; if the observer controlled the query, it's pretty obvious that the self-similarity has to have come from the PasswordMessage. Rinse and repeat. That doesn't cover the case where the password itself is low-entropy, either. "hellohellohellohello" at least has length, but once you compress it that collapses. So an attacker can passively monitor for shorter password packets and know which user to target first. --Jacob
