On Mon, Feb 22, 2021 at 12:28 PM Daniel Gustafsson <dan...@yesql.se> wrote: > > > On 22 Feb 2021, at 11:52, Magnus Hagander <mag...@hagander.net> wrote: > > > > On Thu, Feb 18, 2021 at 1:51 PM Daniel Gustafsson <dan...@yesql.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/
