Re: Disallow SSL compression?

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

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.

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