On 08.02.2019 10:14, Andres Freund wrote:
> Hi,
>
> On 2018-03-30 15:53:39 +0300, Konstantin Knizhnik wrote:
>> Taken in account that vulnerability was found in SSL compression and so
>> SSLComppression is considered to be deprecated and insecure
>> (http://www.postgresql-archive.org/disable-SSL-compression-td6010072.html),
>> it will be nice to have some alternative mechanism of reducing libpq
>> traffic.
>>
>> I have implemented some prototype implementation of it (patch is attached).
>> To use zstd compression, Postgres should be configured with --with-zstd.
>> Otherwise compression will use zlib unless it is disabled by --without-zlib
>> option.
>> I have added compression=on/off parameter to connection string and -Z option
>> to psql and pgbench utilities.
>> Below are some results:
> I think compression is pretty useful, and I'm not convinced that the
> threat model underlying the attacks on SSL really apply to postgres. But
> having said that, have you done any analysis of whether your
> implementation has the same issues?
Sorry, I am not an expert in security area, so I cannot perform analysis
whether using compression in SSL protocol
is vulnerable and is it really applicable to libpq communication between
Postgres client and server.
The main idea of compression implementation at libpq level was not to
solve this possible vulnerability
(I am also not convinced that such kind of attack is applicable to
postgres client-server communication)
but reduce traffic without requirement to use SSL (which may not be
possible or convenient because of many other reasons
not only related with potential vulnerability). Also I believe (although
I have not performed this test yet)
that zstd compression is much more efficient than one used in SSL both
in speed and compression ratio.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company