Re: [PATCH] Reload SSL certificates on SIGHUP

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Andreas Karlsson <andreas(at)proxel(dot)se>, Michael Banck <michael(dot)banck(at)credativ(dot)de>, Peter Geoghegan <pg(at)heroku(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Reload SSL certificates on SIGHUP
Date: 2017-01-04 13:48:36
Message-ID: 20170104134836.GI18360@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> > Magnus Hagander <magnus(at)hagander(dot)net> writes:
> > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >> Before we leave this area, though, there is a loose end that requires
> > >> more thought. That is, what about passphrase-protected server keys?
> > >> ...
> > >> 2. Add a password callback function that would supply the passphrase
> > >> when needed. The question is, where would it get that from? It'd
> > >> be straightforward to supply it from a string GUC, but from a security
> > >> POV it seems pretty silly to have the password in postgresql.conf.
> >
> > > Yeah, that seems like a really bad idea. If you want to do that, then you
> > > might as well just remove the passphrase from the key.
> >
> > Agreed. It's difficult to imagine a situation in which postgresql.conf
> > could be considered more secure than server.key, and usually it'd be less
> > so.
> >
> > >> 3. Add a password callback function that just returns an empty string,
> > >> thereby ensuring a clean failure if the server tries to load a
> > >> passphrase-protected key. We'd still need to change the documentation
> > >> but at least the behavior would be reasonably clean.
> >
> > > Another option would be to use a callback to get the key value the first
> > > time, and then cache it so we can re-use it. That means we can make it
> > work
> > > if the new key has the same password, but it also means we need to take
> > > care of protecting that passphrase. But I'm not sure that's any worse
> > than
> > > the fact that we keep the private key around unlocked today?
> >
> > Yeah, I'm not terribly fussed about having the passphrase sitting in
> > postmaster memory. But the above is work I don't care to do ATM.
> >
> > I think probably the right thing for now is to install a do-nothing
> > callback, so that at least we don't have the issue of the postmaster
> > freezing at SIGHUP. If someone feels like trying to revive support
> > of passphrase-protected server keys, that would be a perfectly fine
> > base to build on; they'd need a callback there anyway.
>
> Does it still support passphrase protected ones on startup, or did that get
> thrown out with the bathwater? I think that's definitely a separate thing
> and there are a nontrivial number of people who would be interested in a
> setup where they can use a passphrase to protect it initially, just not
> reload it.

+1

Thanks!

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2017-01-04 13:52:35 Re: proposal: session server side variables
Previous Message Magnus Hagander 2017-01-04 13:46:11 Re: [PATCH] Reload SSL certificates on SIGHUP