> On 20 May 2024, at 22:48, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, May 20, 2024 at 1:23 PM Jacob Champion
> <jacob.champion@enterprisedb.com> wrote:
>> On Mon, May 20, 2024 at 10:01 AM Robert Haas <robertmhaas@gmail.com> wrote:
>>> I really hope that you can't poke big enough holes to kill the feature
>>> entirely, though. Because that sounds sad.
>>
>> Even if there are holes, I don't think the situation's going to be bad
>> enough to tank everything; otherwise no one would be able to use
>> decompression on the Internet. :D And I expect the authors of the
>> newer compression methods to have thought about these things [1].
>>
>> I hesitate to ask as part of the same email, but what were the plans
>> for compression in combination with transport encryption? (Especially
>> if you plan to compress the authentication exchange, since mixing your
>> LDAP password into the compression context seems like it might be a
>> bad idea if you don't want to leak it.)
>
> 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
guesshow correlated they are.
Best regards, Andrey Borodin.