On Fri, Oct 17, 2014 at 1:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This looks to me like re-fighting the last war. Such a GUC has zero value
> *unless* some situation exactly like the POODLE bug comes up again, and
> the odds of that are not high.
I think it's pretty common for flaws to be discovered in particular
protocols - usually, but not always, the oldest ones. The cost of
adding a new GUC seems pretty small tom me compared to the appealing
potential for users to secure their installation by changing a
configuration setting rather than, say, having to wait for new
packages to be available to install.
> Moreover, the GUC could easily be misused to decrease rather than increase
> one's security, if it's carelessly set. Remember that we only recently
> fixed bugs that prevented use of the latest TLS version. If we have a
> setting like this, I fully anticipate that people will set it to "only use
> TLS 1.2" and then forget that they ever did that; years from now they'll
> still be using 1.2 when it's deprecated.
checkpoint_segments can easily be misused to decrease rather than
increase performance, and autovacuum_naptime can easily be misused to
destroy rather than improve autovacuum behavior. If we only added
GUCs that couldn't be used to make things worse, we'd have no GUCs.
The bottom line for me is that OpenSSL has (a) a seemingly
never-ending supply of serious security flaws and (b) an exposed knob
intended to help users of OpenSSL mitigate the effects of those flaws.
Exposing that knob to our users seems like a good plan; supporting
alternate SSL implementations might be an even better one, not that
the two are mutually exclusive.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company