Re: [PATCH] add ssl_protocols configuration option

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dag-Erling Smørgrav <des(at)des(dot)no>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] add ssl_protocols configuration option
Date: 2014-10-19 17:10:10
Message-ID: CABUevExV9tzx43AcFbw5_Zo3nTtB0A2KJ=+Cr9ZtJ-U7UhRzzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 19, 2014 at 6:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> 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.
>
> That's pretty much isomorphic to just setting the value in the code,
> no?

No, it would let the user (temporarily) override it.

>> 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.
>
> True. But both of those scenarios posit that no *code* changes are
> needed, which is infrequently the case.

Definitely - it's still very borderline if it's useful.

> And you still have the problem that if an admin does change the setting
> away from "default", and forgets to revert that after his next update,
> he could in the long run be less secure not more so. Client-side
> settings would likely be even harder to get rid of than server-side.

True.

> And in the end, if we set values like this from PG --- whether
> hard-wired or via a GUC --- the SSL library people will have exactly
> the same perspective with regards to *our* values. And not without
> reason; we were forcing very obsolete settings up till recently,
> because nobody had looked at the issue for a decade. I see no reason
> to expect that that history won't repeat itself.

The best part would be if we could just leave it up to the SSL
library, but at least the openssl one doesn't have an API that lets us
do that, right? We *have* to pick something...

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Singer 2014-10-19 18:17:45 Re: [PATCH] HINT: pg_hba.conf changed since last config reload
Previous Message Emre Hasegeli 2014-10-19 17:05:17 BRIN range operator class