|From:||Daniel Gustafsson <daniel(at)yesql(dot)se>|
|To:||PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Disallow SSL compression?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
A few years ago we discussed whether to disable SSL compression  which ended
up with it being off by default combined with a recommendation against it in
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).
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?
Daniel Gustafsson https://vmware.com/
|Next Message||Andy Fan||2021-02-18 12:58:13||Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)|
|Previous Message||Peter Eisentraut||2021-02-18 12:49:02||Re: Printing LSN made easy|