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