Re: Disallow SSL compression?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Disallow SSL compression?
Date: 2021-02-22 10:52:15
Message-ID: CABUevEyNraYL9o6hK+AmGhrDe0nM3WuagNDRs35pPw=8MPPNxg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> 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...

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".

--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-02-22 11:27:38 Re: Disallow SSL compression?
Previous Message Önder Kalacı 2021-02-22 10:45:11 Re: row filtering for logical replication