From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | 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-03 15:54:55 |
Message-ID: | 23913.1483458895@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2017-01-03 15:58:25 | Re: merging some features from plpgsql2 project |
Previous Message | Robert Haas | 2017-01-03 15:50:54 | Re: Proposal for changes to recovery.conf API |