On 22.02.2021 23:44, Tom Lane wrote:
Robert Haas <robertmh...@gmail.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.
