On Tue, Jan 3, 2017 at 4:54 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Tue, Jan 3, 2017 at 4:02 AM, Tom Lane <t...@sss.pgh.pa.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/
