Re: Disallow SSL compression?

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Disallow SSL compression?
Date: 2021-02-26 19:34:08
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 26 Feb 2021, at 11:02, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>> On 22 Feb 2021, at 11:52, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

>>> Agreed. It will also help with not having to implement it in new SSL
>>> implementations I'm sure :)
>> Not really, no other TLS library I would consider using actually has
>> compression (except maybe wolfSSL?). GnuTLS and NSS both removed it, and
>> Secure Transport and Schannel never had it AFAIK.
> Ah, well, you'd still have to implement some empty placeholder :)


>>>> The attached removes sslcompression to see what it would look like. The server
>>>> actively disallows it and the parameter is removed, but the sslcompression
>>>> column in the stat view is retained. An alternative could be to retain the
>>>> parameter but not act on it in order to not break scripts etc, but that just
>>>> postpones the pain until when we inevitably do remove it.
>>>> Thoughts? Any reason to keep supporting SSL compression or is it time for v14
>>>> to remove it? Are there still users leveraging this for protocol compression
>>>> without security making it worthwhile to keep?
>>> When the last round of discussion happened, I had multiple customers
>>> who did exactly that. None of them do that anymore, due to the pain of
>>> making it work...
>> Unsurprisingly.
>>> I think for libpq we want to keep the option for a while but making it
>>> a no-op, to not unnecessarily break systems where people just upgrade
>>> libpq, though. And document it as such having no effect and "will
>>> eventually be removed".
>> Agreed, that's better.
> In fact, pg_basebackup with -R will generate a connection string that
> includes sslcompression=0 when used today (unless you jump through the
> hoops to make it work), so not accepting that noe would definitely
> break a lot of things needlessly.

Yup, and as mentioned elsewhere in the thread the standard way of doing it is
to leave the param behind and just document it as not in use. Attached is a v2
which retains the sslcompression parameter for backwards compatibility.

Daniel Gustafsson

Attachment Content-Type Size
v2-0001-Disallow-SSL-compression.patch application/octet-stream 6.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-02-26 19:36:41 Re: [PATCH] pgbench: Remove ecnt, a member variable of CState
Previous Message Alejandro Sánchez 2021-02-26 19:09:20 Systems Integration and Raising of the Abstraction Level