Re: [PATCH] Reload SSL certificates on SIGHUP

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.

>
> > That said, they passphrase should only be required if the key changes,
> not
> > if the certificate changes, I believe. Do we take advantage of this today
> > (sorry, haven't looked at the code)? Because the most common operation is
> > probably the renewal of a certificate, which does not change the key, for
> > example...
>
> As I just explained to Peter, we don't have any way to exploit that given
> the design of loading a whole new SSL_CTX.
>

Bummer.

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