Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-12 0:29 +0200]: > The option is there already, it's called "none". That's what people are > asking for - they don't care who they are connecting to, just that the > traffic is encrypted (be it legitimate or hacked traffic, at least it's > encrypted). For the record, I don't agree. SSL certificate validation is good, and should be done as long as you have a cert installed. Encryption without authentication is not worth a lot, after all. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-11 11:50 +0200]: > It treats self-signed certificates the same way it treats anything else. > In the case of a self-signed one, the certificate and the CA certificate > are the same. Thus, you have to copy the server certificate to the client. Right, that's what I had expected. Thanks for confirming. > > I had thought it checks whether the user has the server signing > > certificate of the server installed on his client home directory > > (which, BTW, seems like a strange place to default to, and thus keep > > it). > > That has just been brought up from previous versions. Perhaps we need to > have a system wide root store as well - then you could point that to > whatever snakeoil store you have, and it would find the cert correctly? We couldn't set this up by default, of course, since each installed machine will have a different snakeoil cert (it gets generated during installation). But at least the servers I know often use something like /etc/ssl/certs/.crt and point their services (like apache, postfix, etc.) to this. However, right now the client side psql does not have any system wide configuration files, so adding something like this will need some careful design. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander [2009-04-12 0:58 +0200]: > Which means that every time I connect, I need to first to make sure that > the file is there, and that the proper user has permissions to read the > file, *before* I connect. Arguably the connection should fail if the file is present, but cannot be read because of permission or syntax errors. That's exactly how the server side behaves as well, and IMHO it's the right thing to do. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Hello Bruce, Bruce Momjian [2009-04-11 8:33 -0400]: > I noticed you didn't quote the next sentence: > > The SSL connection will fail if the server does not present a trusted > certificate. Indeed. When I read it first, it seemed unrelatead to me, but now I understand where this was aiming at. > Which clearly explains _a_ failure, but doesn't link it well to the > behavior. I agree the wording needs improvement so I have update the > doc paragraph to mention "requires" at the beginning": > > I will now look at improving the libpq error message. I saw your patches. Many thanks, this is much clearer now. Bruce Momjian [2009-04-11 17:42 -0400]: > The only other approach would be to add an sslverify value of > 'try' that tries only if root.crt exists. The semantics of this sound like a good default to me, since it would enforce a good cert as soon as I start caring, i. e. when I actually have a root.crt to verify against. This is the kind of "single-action SSL enabling" workflow I was already looking for when configuring the snakeoil SSL cert by default. Perhaps it shouldn't be called "try", though, maybe "cert" should have above semantics, and "force" should have the currently implemented one (i. e. fail if not present)? But that gets us dangerously close to bikeshedding now... Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
* Martin Pitt (mp...@debian.org) wrote: > For the record, I don't agree. SSL certificate validation is good, and > should be done as long as you have a cert installed. Encryption > without authentication is not worth a lot, after all. I disagree, and you *can* do authentication without SSL! The big one being Kerberos/GSSAPI which gives both server and client authentication. There's a big difference between man-in-the-middle attacks and passive network monitoring. Certainly, we should do validation where it's *possible* to do it, but I don't think we should throw out encryption just because we don't have a root cert available for use. If we don't have a certificate it's not possible to validate *anyone*. That's going to be the case for packagers and I just can't imagine asking them to ship a broken configuration. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
* Martin Pitt (mp...@debian.org) wrote: > Magnus Hagander [2009-04-11 11:50 +0200]: > > That has just been brought up from previous versions. Perhaps we need to > > have a system wide root store as well - then you could point that to > > whatever snakeoil store you have, and it would find the cert correctly? > > We couldn't set this up by default, of course, since each installed > machine will have a different snakeoil cert (it gets generated during > installation). It's worse than that.. Obviously, you can have the client installed on systems which aren't where the server is (we do this alot..) and there's no way for a packaging system to pull the cert from the server. > But at least the servers I know often use something > like /etc/ssl/certs/.crt and point their services (like > apache, postfix, etc.) to this. However, right now the client side > psql does not have any system wide configuration files, so adding > something like this will need some careful design. If we're going to do something along those lines, we should start by supporting a CA cert directory or similar. We could then recommend ca-certificates and default config the client to use those. Of course, anyone who actually cares about security probably wouldn't install ca-certificates, but it's what the browsers use. Thanks, Stephen signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Stephen Frost [2009-04-14 9:09 -0400]: > I disagree, and you *can* do authentication without SSL! I know. But then you do have authentication as well, which was exactly my point. Also, I said "not a lot better", not "totally useless". Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Stephen Frost [2009-04-14 9:18 -0400]: > * Martin Pitt (mp...@debian.org) wrote: > > We couldn't set this up by default, of course, since each installed > > machine will have a different snakeoil cert (it gets generated during > > installation). > > It's worse than that.. Obviously, you can have the client installed on > systems which aren't where the server is (we do this alot..) and there's > no way for a packaging system to pull the cert from the server. Of course I assumed that the server and client are on different systems. If they are on the same, then we just use the Unix socket and don't need all this SSL fuss at all. > If we're going to do something along those lines, we should start by > supporting a CA cert directory or similar. We could then recommend > ca-certificates and default config the client to use those. Of course, > anyone who actually cares about security probably wouldn't install > ca-certificates, but it's what the browsers use. Hm, that sounds like opening a can of worms, TBH. But yes, once the final defaults in psql are agreed upon, we can discuss the packaging. Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
On Sunday 12 April 2009 12:52:53 Magnus Hagander wrote: > This is a different way to do bruces suggestion of a different > default. That's possibly even clearer. So I can definitely go with > this, but I think two different parameters makes it more clear and is > better. I think altogether changing the default ssmode to disable would solve all the problems with the least amount of work, complication, and controversy. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
On Tuesday 14 April 2009 17:05:45 Martin Pitt wrote: > Of course I assumed that the server and client are on different > systems. If they are on the same, then we just use the Unix socket and > don't need all this SSL fuss at all. That's what you think. Just read the hackers thread about SSL over Unix- domain sockets. ;-) -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Magnus Hagander wrote:
> On 14 apr 2009, at 04.33, Bruce Momjian wrote:
>
> > Magnus Hagander wrote:
> >>> I would actually call the two parameters 'verify-cert' and 'verify-
> >>> cn',
> >>> and document that they also have "require" behavior. Obviously you
> >>> can't verify certificates unless you require SSL.
> >>
> >> I would prefer having "verify", "verify-no-cn" and "no-verify" or
> >> something like that. Making it the "default choice" to have
> >> verification
> >> enabled, and very clear that you're turning something off if you're
> >> not.
> >> And then just map require to verify. Or they could be "require-no-cn"
> >> and "require-no-cert" perhaps?
> >>
> >> ("default choice" only for those using ssl of course - we'd still
> >> have
> >> "disable" as the default *value* of the parameter)
> >
> > I think the "no" options are odd because they have _negative_
> > designations.
>
> That's the intention. When you're turning off something, I think it
> makes sense to use "no"
But that doesn't scale: sslmode currently has four options, soon
perhaps to be six. The idea is that the items should be of increasing
security, and adding "no" in the middle doesn't allow that to be clear.
In fact there are too many sslmode options to list them in a paragraph;
it should be an SGML table; I will work on that now.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Applied. Depending on how we handle this the error text might need to change but odds are we will still need to report something related to sslmode/sslverify when root.crt is missing. --- Bruce Momjian wrote: > Peter Eisentraut wrote: > > On Friday 10 April 2009 08:39:33 Martin Pitt wrote: > > > Tom Lane [2009-04-10 1:15 -0400]: > > > > Martin Pitt writesyuqhom#3: > > > > > The test suite detected one regression in libpq, though: Setting > > > > > $PGHOST now complains about a missing root.crt, although this is only > > > > > relevant on the server side (or did I misunderstood this?) > > > > > > > > No, that's a progression: the client wants to validate the server's > > > > cert, too. > > > > > > Indeed it is nice to see this feature (great to prevent spoofing), but > > > if I don't have a ~/.postgresql/root.crt at all, it shouldn't > > > certainly break completely? (which it does now). > > > > I assume the server has the snakeoil certificate installed? In that case, > > it > > is correct that the client refuses to proceed, although the exact manner of > > breaking could perhaps be improved. > > I have developed a patch to more clearly explain the problem with a > missing client root.crt file: > > $ PGSSLVERIFY=cn sql -h localhost test > psql: root certificate file "/u/postgres/.postgresql/root.crt" does not > exist > Either supply the file or set sslverify to "none" to disable server > certificate verification. > > $ PGSSLVERIFY=none sql -h localhost test > psql (8.4beta1) > SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256) > Type "help" for help. > > I had to add a second error message line; I didn't see us doing a > second line anywhere else in libpq, but it seemed to be the only > solution. Should I use three lines? > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] libpq 8.4 beta1: $PGHOST complains about missing root.crt
Bruce Momjian wrote: > > That's the intention. When you're turning off something, I think it > > makes sense to use "no" > > But that doesn't scale: sslmode currently has four options, soon > perhaps to be six. The idea is that the items should be of increasing > security, and adding "no" in the middle doesn't allow that to be clear. > > In fact there are too many sslmode options to list them in a paragraph; > it should be an SGML table; I will work on that now. OK, I have created an SGML table to show the sslmode options. While doing that I found that 'disable' was misstated as "attempt only an unencrypted SSL connection". Neither Magnus nor I know what an unencrypted SSL connection is, so we assume it is an error. I have instead replaced it with "try a non-SSL connection". When this was a paragraph it was hard to see that mistake; in an SGML table it was obvious. Patch attached and applied. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/libpq.sgml === RCS file: /cvsroot/pgsql/doc/src/sgml/libpq.sgml,v retrieving revision 1.283 diff -c -c -r1.283 libpq.sgml *** doc/src/sgml/libpq.sgml 11 Apr 2009 16:46:54 - 1.283 --- doc/src/sgml/libpq.sgml 14 Apr 2009 20:37:02 - *** *** 254,276 This option determines whether or with what priority a SSL TCP/IP connection will be negotiated with the !server. There are four modes: disable will attempt !only an unencrypted SSL connection; !allow will negotiate, trying first a !non-SSL connection, then if that fails, trying an !SSL connection; prefer (the default) !will negotiate, trying first an SSL connection, !then if that fails, trying a regular non-SSL !connection; require will try only an !SSL connection. sslmode is ignored !for Unix domain socket communication. ! If PostgreSQL is compiled without SSL support, using option require will cause an error, while options allow and prefer will be !accepted but libpq will not in fact attempt an SSL connection.SSLwith libpq --- 254,308 This option determines whether or with what priority a SSL TCP/IP connection will be negotiated with the !server. There are four modes: ! ! ! sslmode options ! ! ! !Option !Description ! ! ! ! ! ! !disable !only try a non-SSL connection ! ! ! !allow !first try a non-SSL ! connection; if that fails, try an SSL ! connection ! ! ! !prefer (default) !first try an SSL connection; if !that fails, try a non-SSL !connection ! ! ! !require !only try an SSL connection ! ! ! ! ! +sslmode is ignored for Unix domain socket +communication. If PostgreSQL is compiled without SSL support, using option require will cause an error, while options allow and prefer will be !accepted but libpq will not actually attempt an SSL connection.SSLwith libpq -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] PostgreSQL Windows XP Installer Problem
Your name : Dwight Wilcox Your email address : dwight.wil...@navy.mil System Configuration - - Architecture : Intel Pentium Operating System : Windows XP PostgreSQL version : postgresql-8.3.7-1-windows.exe Compiler used : not applicable Please enter a FULL description of your problem: - Obtain installer from http://www.postgresql.org/download/windows. Attempted to install on Windows XP system with no previous postgresql. Used only installer defaults except for postgres user password. Installer created but did not place any files in folder C:\Program Files\PostgresSQL\8.3\data. Installer generated message that it couldn't read file C:\Program Files\PostgresSQL\8.3\data\postgresql.conf --no surprise since nothing there. Clicking OK allowed installer to Finish. Resulting service postgresql-8.3 would appear to be able to start but stops after about a minute with an error code of 2 and no other indication I could see of what was wrong. Tried copying sample file from share folder, renamed, and pasted into data folder but that didn't help. Also tried setting system environment variable PGDATA and still no luck. Other tools don't work because service could not be started successfully.
