Re: [PATCH] add ssl_protocols configuration option

On Fri, Oct 17, 2014 at 7:08 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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.

If anything, I think the default should be "default", and then we have
that map out to something. Because once you've initdb'ed, the config
file wil be stuck with a default and we can't change that in a minor
release *if* something like POODLE shows up again. It would require an
admin action, and in this case, it would make us less secure. If we
had a GUC that took the keyword "default" which would mean "whatever
the current version of postgresql thinks is the best" then we could
change the default in a security update if something showed up.

In a case like POODLE we probably wouldn't have done it anyway, as it
doesn't affect our connections (we're not http) and it would have the
potential of breaking some third party clients. However, if something
really bad showed up, we might want to do that.

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

Having the guc could certainly be useful in some cases. If we do, we
should of course *also* have a corresponding configuration option in
libpq, so I'd say this patch is incomplete if we do want to do it.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/