Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Dag-Erling Sm�rgrav wrote:
>> I understand this policy. However, this new feature a) has absolutely
>> no impact unless the admin makes a conscious decision to use it and b)
>> will make life much easier for everyone if a POODLE-like vulnerability
>> is discovered in TLS.
> I see this as vaguely related to
> http://www.postgresql.org/message-id/20131114202733.GB7583@eldon.alvh.no-ip.org
> where we want to have SSL behavior configurable in the back branches due
> to renegotiation issues: there was talk in that thread about introducing
> new GUC variables in back branches to control the behavior. The current
> patch really doesn't add much in the way of features (SSLv3 support and
> so on already exist in back branches) --- what it does add is a way to
> control whether these are used.
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.
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.
So I think the argument that this is a useful security contribution is
pretty weak; and on the whole we don't need another marginally-useful GUC.
regards, tom lane