Re: Disallow SSL compression?

> 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 :)

Correct.

>>>> 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 https://vmware.com/