Re: libpq compression

On 22.02.2021 23:44, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> So at the end of the day I'm not really quite sure what is best here.
>> I agree with all of Craig's points about the advantages of
>> packet-level compression, so I'd really prefer to make that approach
>> work if we can. However, it also seems to me that there's room to be
>> fairly concerned about what these test results are showing.
> BTW ... in view of the nearby thread about permanently disabling
> OpenSSL's compression option, I wonder whether we really ought to be
> in a hurry to put back compression underneath that. While this area
> is out of my wheelhouse, my understanding of the problem with OpenSSL
> is that the packet length changes due to compression can provide
> enough information to an attacker to break the encryption. It seems
> to me that do-it-ourselves compression would most likely create an
> equivalent vulnerability.
>
> Perhaps that problem can be dodged by refusing to use compression
> if any form of encryption is in use ... but that would make for
> another big reduction in the scope of usefulness of this feature.
> Connections on which you'd care about compression are likely to be
> across open networks where encryption is an even more pressing need.
>
> regards, tom lane
It is true that compression can compromise encryption,
but how it can compromise plain text messages?
It certainly doesn't make communication more secure, but definitely
it doesn't make it less secure!

Please also notice that compression is first of all needed for bulk data
loading and replication.
And in many cases this traffic is internal, so no attacks are expected here.
It is actually one of the arguments why compression at libpq level is
needed - why we can not rely
on SSL compression. If we speak about internal network, establishing SSL
connection make no sense
and just adds extra overhead.