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-22 11:27:38 |
Message-ID: | 2DD926F5-5A4E-4844-A8B8-C1CD62469B27@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 22 Feb 2021, at 11:52, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>>
>> A few years ago we discussed whether to disable SSL compression [0] which ended
>> up with it being off by default combined with a recommendation against it in
>> the docs.
>>
>> OpenSSL themselves disabled SSL compression by default in 2016 in 1.1.0 with
>> distros often having had it disabled for a long while before then. Further,
>> TLSv1.3 removes compression entirely on the protocol level mandating that only
>> NULL compression is allowed in the ClientHello. NSS, which is discussed in
>> another thread, removed SSL compression entirely in version 3.33 in 2017.
>>
>> It seems about time to revisit this since it's unlikely to work anywhere but in
>> a very small subset of system setups (being disabled by default everywhere) and
>> is thus likely to be very untested at best. There is also the security aspect
>> which is less clear-cut for us compared to HTTP client/servers, but not refuted
>> (the linked thread has a good discussion on this).
>
> 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.
>> 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.
--
Daniel Gustafsson https://vmware.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2021-02-22 11:28:52 | pgsql: pg_collation_actual_version() -> pg_collation_current_version(). |
Previous Message | Magnus Hagander | 2021-02-22 10:52:15 | Re: Disallow SSL compression? |