Re: [HACKERS] controlling the location of server-side SSL files
Peter Eisentraut writes:
> On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote:
>> Hm? Obviously I misunderstood what changes you were proposing to make,
>> so would you mind spelling it out?
> The details are to be determined, but a possible change would likely be
> that instead of looking for a file and using it if and only if found,
> there would be some kind of connection parameter saying "use this file
> for this functionality", and otherwise it's not used. The particular
> example would be the CRL file.
Mph. That seems unlikely to be a net win to me. The scenario I'm
imagining is that you ("you" being DBA for some group of people) didn't
have a CRL file before, and now you need one. Your administration
problem is to get that CRL file into place for all your users.
If we change as above, then you still have that admin problem, plus now
you have another: getting all your users to use the new connection
parameter. Which, as a rule, is going to be tough (for example, psql
has no easy way to make that happen). The new admin problem offers you
no leverage at all on the old one, either, since a user who's not
acquired the CRL file more than likely hasn't changed his connection
habits either.
There may or may not be some value in a connection parameter that allows
specifying a location besides ~/.postgresql/ for the SSL support files.
But I don't find any attraction in changing the default behavior.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On ons, 2012-02-29 at 14:27 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote: > >> In particular, I observe that we get pushback anytime we break something > >> in a way that makes SSL config files be required on the client side; > >> see bug #6302 for most recent example. > > > *If* we were to make a change in libpq analogous to the server side, the > > effect would be to make the files less required, which could actually > > help the case of bug #6302. > > Hm? Obviously I misunderstood what changes you were proposing to make, > so would you mind spelling it out? The details are to be determined, but a possible change would likely be that instead of looking for a file and using it if and only if found, there would be some kind of connection parameter saying "use this file for this functionality", and otherwise it's not used. The particular example would be the CRL file. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
Peter Eisentraut writes: > On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote: >> In particular, I observe that we get pushback anytime we break something >> in a way that makes SSL config files be required on the client side; >> see bug #6302 for most recent example. > *If* we were to make a change in libpq analogous to the server side, the > effect would be to make the files less required, which could actually > help the case of bug #6302. Hm? Obviously I misunderstood what changes you were proposing to make, so would you mind spelling it out? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On ons, 2012-02-29 at 14:20 -0500, Tom Lane wrote: > In particular, I observe that we get pushback anytime we break something > in a way that makes SSL config files be required on the client side; > see bug #6302 for most recent example. *If* we were to make a change in libpq analogous to the server side, the effect would be to make the files less required, which could actually help the case of bug #6302. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
Peter Eisentraut writes: > On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote: >> Yes, ignoring a missing file in a security context is definitely not good. >> It should throw an error. >> >> We have a few bad defaults from the old days around SSL for this, but if it >> requires breaking backwards compatibility to get it right, I think we >> should still do it. > Btw., should we also consider making similar changes on the libpq side? I think that breaking compatibility of libpq's behavior is a whole lot harder sell than changing things in a way that only affects what people have to put into postgresql.conf. We've always treated the latter as something that can change across major versions. In particular, I observe that we get pushback anytime we break something in a way that makes SSL config files be required on the client side; see bug #6302 for most recent example. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote: > > I'm still worried about this. If we ignore a missing root.crt, then the > > effect is that authentication and certificate verification might fail, > > which would be annoying, but you'd notice it soon enough. But if we > > ignore a missing root.crl, we are creating a security hole. > > > > Yes, ignoring a missing file in a security context is definitely not good. > It should throw an error. > > We have a few bad defaults from the old days around SSL for this, but if it > requires breaking backwards compatibility to get it right, I think we > should still do it. Btw., should we also consider making similar changes on the libpq side? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On ons, 2012-02-08 at 09:16 +0100, Magnus Hagander wrote: > > My best idea at the moment is that we should set these parameters to > > empty by default, and make users point them to existing files if they > > want to use that functionality. Comments? > > > > +1. Anybody who actually cares about setting up security is likely not > going to rely on defaults anyway - and is certainly going to review > whatever they are. So there should be no big problem there. Updated patch to reflect this. *** i/doc/src/sgml/config.sgml --- w/doc/src/sgml/config.sgml *** *** 668,673 SET ENABLE_SEQSCAN TO OFF; --- 668,737 + + ssl_ca_file (string) + +ssl_ca_file configuration parameter + + + + Specifies the name of the file containing the SSL server certificate + authority (CA). The default is empty, meaning no CA file is loaded, + and client certificate verification is not performed. (In previous + releases of PostgreSQL, the name of this file was hard-coded + as root.crt.) Relative paths are relative to the + data directory. This parameter can only be set at server start. + + + + + + ssl_cert_file (string) + +ssl_cert_file configuration parameter + + + + Specifies the name of the file containing the SSL server certificate. + The default is server.crt. Relative paths are + relative to the data directory. This parameter can only be set at + server start. + + + + + + ssl_crl_file (string) + +ssl_crl_file configuration parameter + + + + Specifies the name of the file containing the SSL server certificate + revocation list (CRL). The default is empty, meaning no CRL file is + loaded. (In previous releases of PostgreSQL, the name of this file was + hard-coded as root.crl.) Relative paths are + relative to the data directory. This parameter can only be set at + server start. + + + + + + ssl_key_file (string) + +ssl_key_file configuration parameter + + + + Specifies the name of the file containing the SSL server private key. + The default is server.key. Relative paths are + relative to the data directory. This parameter can only be set at + server start. + + + + ssl_renegotiation_limit (integer) *** i/doc/src/sgml/runtime.sgml --- w/doc/src/sgml/runtime.sgml *** *** 1831,1840 pg_dumpall -p 5432 | psql -d postgres -p 5433 SSL certificates and make sure that clients check the server's certificate. To do that, the server must be configured to accept only hostssl connections () and have SSL !server.key (key) and !server.crt (certificate) files (). The TCP client must connect using sslmode=verify-ca or verify-full and have the appropriate root certificate file installed (). --- 1831,1838 SSL certificates and make sure that clients check the server's certificate. To do that, the server must be configured to accept only hostssl connections () and have SSL key and certificate files !(). The TCP client must connect using sslmode=verify-ca or verify-full and have the appropriate root certificate file installed (). *** *** 2053,2062 pg_dumpall -p 5432 | psql -d postgres -p 5433 !To start in SSL mode, the files server.crt !and server.key must exist in the server's data directory. !These files should contain the server certificate and private key, !respectively. On Unix systems, the permissions on server.key must disallow any access to world or group; achieve this by the command chmod 0600 server.key. --- 2051,2062 !To start in SSL mode, files containing the server certificate !and private key must exist. By default, these files are expected to be !named server.crt and server.key, respectively, in !the server's data directory, but other names and locations can be specified !using the configuration parameters !and . On Unix systems, the permissions on server.key must disallow any access to world or group; achieve this by the command chmod 0600 server.key. *** *** 2144,2170 pg_dumpall -p 5432 | psql -d postgres -p 5433 ! $PGDATA/server.crt server certificate sent to client to indicate server's identity ! $PGDATA/server.key server private key proves server certificate was sent by the owner; does not indicate certificate owner is trustworthy ! $PGDATA/root.crt trusted certificate author
Re: [HACKERS] controlling the location of server-side SSL files
On Tuesday, February 7, 2012, Peter Eisentraut wrote: > On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote: > > > > One thing that is perhaps worth thinking about: Currently, we just > > > > ignore missing root.crt and root.crl files. With this patch, we > still > > > > do this, even if the user has given a specific nondefault location. > > > > That seems a bit odd, but I can't think of a simple way to do it > better. > > > > > > There's a review in the CF app for this finding only minor issues, so > > > I'm marking this patch therein as "Ready for Committer". > > > > OK, no one had any concerns about the missing file behavior I > > described above? If not, then I'll commit it soon. > > I'm still worried about this. If we ignore a missing root.crt, then the > effect is that authentication and certificate verification might fail, > which would be annoying, but you'd notice it soon enough. But if we > ignore a missing root.crl, we are creating a security hole. > Yes, ignoring a missing file in a security context is definitely not good. It should throw an error. We have a few bad defaults from the old days around SSL for this, but if it requires breaking backwards compatibility to get it right, I think we should still do it. My best idea at the moment is that we should set these parameters to > empty by default, and make users point them to existing files if they > want to use that functionality. Comments? > +1. Anybody who actually cares about setting up security is likely not going to rely on defaults anyway - and is certainly going to review whatever they are. So there should be no big problem there. //Magnus -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Re: [HACKERS] controlling the location of server-side SSL files
On tis, 2012-01-24 at 22:05 +0200, Peter Eisentraut wrote: > > > One thing that is perhaps worth thinking about: Currently, we just > > > ignore missing root.crt and root.crl files. With this patch, we still > > > do this, even if the user has given a specific nondefault location. > > > That seems a bit odd, but I can't think of a simple way to do it better. > > > > There's a review in the CF app for this finding only minor issues, so > > I'm marking this patch therein as "Ready for Committer". > > OK, no one had any concerns about the missing file behavior I > described above? If not, then I'll commit it soon. I'm still worried about this. If we ignore a missing root.crt, then the effect is that authentication and certificate verification might fail, which would be annoying, but you'd notice it soon enough. But if we ignore a missing root.crl, we are creating a security hole. My best idea at the moment is that we should set these parameters to empty by default, and make users point them to existing files if they want to use that functionality. Comments? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On tor, 2012-01-19 at 15:44 -0500, Robert Haas wrote: > On Sat, Jan 14, 2012 at 8:40 AM, Peter Eisentraut wrote: > > On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote: > >> I think I would like to have a set of GUC parameters to control the > >> location of the server-side SSL files. > > > > Here is the patch for this. > > > > One thing that is perhaps worth thinking about: Currently, we just > > ignore missing root.crt and root.crl files. With this patch, we still > > do this, even if the user has given a specific nondefault location. > > That seems a bit odd, but I can't think of a simple way to do it better. > > There's a review in the CF app for this finding only minor issues, so > I'm marking this patch therein as "Ready for Committer". OK, no one had any concerns about the missing file behavior I described above? If not, then I'll commit it soon. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On Sat, Jan 14, 2012 at 8:40 AM, Peter Eisentraut wrote: > On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote: >> I think I would like to have a set of GUC parameters to control the >> location of the server-side SSL files. > > Here is the patch for this. > > One thing that is perhaps worth thinking about: Currently, we just > ignore missing root.crt and root.crl files. With this patch, we still > do this, even if the user has given a specific nondefault location. > That seems a bit odd, but I can't think of a simple way to do it better. There's a review in the CF app for this finding only minor issues, so I'm marking this patch therein as "Ready for Committer". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On mån, 2012-01-02 at 06:32 +0200, Peter Eisentraut wrote: > I think I would like to have a set of GUC parameters to control the > location of the server-side SSL files. Here is the patch for this. One thing that is perhaps worth thinking about: Currently, we just ignore missing root.crt and root.crl files. With this patch, we still do this, even if the user has given a specific nondefault location. That seems a bit odd, but I can't think of a simple way to do it better. diff --git i/doc/src/sgml/config.sgml w/doc/src/sgml/config.sgml index 0cc3296..519715f 100644 --- i/doc/src/sgml/config.sgml +++ w/doc/src/sgml/config.sgml @@ -668,6 +668,66 @@ SET ENABLE_SEQSCAN TO OFF; + + ssl_ca_file (string) + + ssl_ca_file configuration parameter + + + +Specifies the name of the file containing the SSL server certificate +authority. The default is root.crt. Relative +paths are relative to the data directory. This parameter can only be +set at server start. + + + + + + ssl_cert_file (string) + + ssl_cert_file configuration parameter + + + +Specifies the name of the file containing the SSL server certificate. +The default is server.crt. Relative paths are +relative to the data directory. This parameter can only be set at +server start. + + + + + + ssl_crl_file (string) + + ssl_crl_file configuration parameter + + + +Specifies the name of the file containing the SSL server certificate +revocation list. The default is root.crl. +Relative paths are relative to the data directory. This parameter can +only be set at server start. + + + + + + ssl_key_file (string) + + ssl_key_file configuration parameter + + + +Specifies the name of the file containing the SSL server private key. +The default is server.key. Relative paths are +relative to the data directory. This parameter can only be set at +server start. + + + + ssl_renegotiation_limit (integer) diff --git i/doc/src/sgml/runtime.sgml w/doc/src/sgml/runtime.sgml index 1c3a9c8..a855279 100644 --- i/doc/src/sgml/runtime.sgml +++ w/doc/src/sgml/runtime.sgml @@ -1831,10 +1831,8 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 SSL certificates and make sure that clients check the server's certificate. To do that, the server must be configured to accept only hostssl connections () and have SSL - server.key (key) and - server.crt (certificate) files (). The TCP client must connect using + linkend="auth-pg-hba-conf">) and have SSL key and certificate files + (). The TCP client must connect using sslmode=verify-ca or verify-full and have the appropriate root certificate file installed (). @@ -2053,10 +2051,12 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 - To start in SSL mode, the files server.crt - and server.key must exist in the server's data directory. - These files should contain the server certificate and private key, - respectively. + To start in SSL mode, files containing the server certificate + and private key must exist. By default, these files are expected to be + named server.crt and server.key, respectively, in + the server's data directory, but other names and locations can be specified + using the configuration parameters + and . On Unix systems, the permissions on server.key must disallow any access to world or group; achieve this by the command chmod 0600 server.key. @@ -2144,27 +2144,27 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 - $PGDATA/server.crt + ($PGDATA/server.crt) server certificate sent to client to indicate server's identity - $PGDATA/server.key + ($PGDATA/server.key) server private key proves server certificate was sent by the owner; does not indicate certificate owner is trustworthy - $PGDATA/root.crt + ($PGDATA/root.crt) trusted certificate authorities checks that client certificate is signed by a trusted certificate authority - $PGDATA/root.crl + ($PGDATA/root.crl) certificates revoked by certificate authorities client certificate must not be on this list @@ -2176,6 +2176,7 @@ pg_dumpall -p 5432 | psql -d postgres -p 5433 The files server.key, server.crt, root.crt, and root.crl +(or their configured alternative names) are only examined during server start; so you must restart the server for changes in them to take effect. diff --git i/src/backend/libpq/be-secure.c w/src/backend/libpq/be-secure.c index e35df73..1e34e56 100644 --- i/src/backend/l
Re: [HACKERS] controlling the location of server-side SSL files
On Tue, Jan 3, 2012 at 9:38 PM, Tom Lane wrote: > Robert Haas writes: >> On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote: >>> [ reasons ] > >> I agree with these reasons. We don't get charged $0.50 per GUC, so >> there's no particular reason to contort things to have fewer of them. > > Well, there definitely is a distributed cost to each additional GUC. > Peter's given what are probably adequate reasons to add several of them > here, but that doesn't mean we should not ask the question whether each > new GUC is really necessary. No argument. I'm merely saying that I think the rationale for these GUCs is solid enough to justify their existence. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
Robert Haas writes: > On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote: >> [ reasons ] > I agree with these reasons. We don't get charged $0.50 per GUC, so > there's no particular reason to contort things to have fewer of them. Well, there definitely is a distributed cost to each additional GUC. Peter's given what are probably adequate reasons to add several of them here, but that doesn't mean we should not ask the question whether each new GUC is really necessary. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote: > On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote: >> Peter Eisentraut writes: >> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote: >> >> Were you thinking one option pointing to a directory or one option per >> >> file? >> >> > One option per file: >> >> That seems like serious overkill. Why not one option specifying the >> directory? What use-case is there for letting them be in different >> directories, let alone letting the DBA choose random names for each one? > > [ reasons ] I agree with these reasons. We don't get charged $0.50 per GUC, so there's no particular reason to contort things to have fewer of them. It's nice where it's possible, of course, but not when it makes people contort things to support the way we think our users should lay out their filesystem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote: > >> Were you thinking one option pointing to a directory or one option per > >> file? > > > One option per file: > > That seems like serious overkill. Why not one option specifying the > directory? What use-case is there for letting them be in different > directories, let alone letting the DBA choose random names for each one? Several consistency reasons: - We provide the same per-file options in libpq. - Indeed, if you use something like dblink or plproxy, these might even point to the same files. - We also have settings for hba_file and ident_file that point to a file. - All other daemons with SSL support known to me, such as mail and web servers, have per-file options. Also some practical reasons: - Yes, choosing random names is important. We have local naming schemes. And I would rather have a descriptive file name for the CA than having them all named root.crt, and if I want to know which one it is I have to look inside the file. - You might not want all of the files in the same directory. CA and CRL might live elsewhere, for example. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
Peter Eisentraut writes: > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote: >> Were you thinking one option pointing to a directory or one option per >> file? > One option per file: That seems like serious overkill. Why not one option specifying the directory? What use-case is there for letting them be in different directories, let alone letting the DBA choose random names for each one? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote: > Were you thinking one option pointing to a directory or one option per > file? One option per file: ssl_cert_file ssl_key_file ssl_ca_file ssl_crl_file This is very similar to the configuration of, for example, Apache, Dovecot, Postfix, so it should be quite familiar to administrators. It also mirrors that we have libpq options to set these things on the client side. (We use the term "root certificate" in libpq, but I think "CA" is more commonly used in these situations. Not sure.) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] controlling the location of server-side SSL files
On Jan 2, 2012 5:33 AM, "Peter Eisentraut" wrote: > > I think I would like to have a set of GUC parameters to control the > location of the server-side SSL files. In a setup that has all the > other configuration files under /etc, the SSL files ought to go there as > well. (For comparison, most email and web servers keep them there.) > Having them in the data directory keeps requiring a bunch of special > treatment in the configuration management set up, and during backup and > recovery. Any concerns about that? > While I personally prefer keeping them in the data directory for backup reasons (clearly different backup reasons than yours though), i agree we should have such an option - for consistency if nothing else. Were you thinking one option pointing to a directory or one option per file? /Magnus
[HACKERS] controlling the location of server-side SSL files
I think I would like to have a set of GUC parameters to control the location of the server-side SSL files. In a setup that has all the other configuration files under /etc, the SSL files ought to go there as well. (For comparison, most email and web servers keep them there.) Having them in the data directory keeps requiring a bunch of special treatment in the configuration management set up, and during backup and recovery. Any concerns about that? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
