Re: disable SSL compression? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: disable SSL compression?
Date
Msg-id CABUevEwRJd2bXkC=sEPfR=91-GJaVUztwX1cAzwba9gx0C00Eg@mail.gmail.com
Whole thread Raw
In response to Re: disable SSL compression?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: disable SSL compression?  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On Fri, Mar 9, 2018 at 3:06 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 3/8/18 14:23, Claudio Freire wrote:
> On Thu, Mar 8, 2018 at 3:40 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> It appears that SSL compression is nowadays deprecated as insecure.
>> Yet, it is still enabled by libpq by default, and there is no way to
>> disable it in the server.  Should we make some changes here?  Does
>> anyone know more about this?
>
> Even if libpq enables it, it has to be enabled both in the client and
> the server for it to work.
>
> OpenSSL disables the whole feature by default, and enabling it is
> rather cumbersome. The result is that, at least with OpenSSL, the
> server and client won't accept compression without extensive fiddling
> by the user.

But however that may be, libpq appears to enable it by default.  This is
what I get from psql:

SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384,
bits: 256, compression: on)


What platform does that actually work out of the box on? I have customers who actively want to use it (for compression, not security -- replication across limited and metered links), and the amount of workarounds they have to put in place OS level to get it working is increasingly complicated.

That said, I think it makes sense to not have libpq enable it by default. The simple change is to just have libpq default to it being off while still allowing it to be turned on. I don't really see any downside of that at all (given the state of the libraries), and it's supposedly a trivial change. 



--

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: FOR EACH ROW triggers on partitioned tables
Next
From: David Steele
Date:
Subject: Re: Fixes for missing schema qualifications