libpq 8.4 beta1: $PGHOST complains about missing root.crt

Martin Pitt <mpitt@debian.org> writes:

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.

regards, tom lane

Tom Lane [2009-04-10 1:15 -0400]:

Martin Pitt <mpitt@debian.org> 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).

libpq did not bump the SONAME, thus this breaks backwards
compatibility with previous PostgreSQL versions which also used
libpq.so.5, i. e. from 8.2 on.

(Oh, and just for the record: I'm not advocating at all to bump the
soname; with thousands of packages linking against it, those are
always painful library transitions).

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

On Friday 10 April 2009 08:39:33 Martin Pitt wrote:

Tom Lane [2009-04-10 1:15 -0400]:

Martin Pitt <mpitt@debian.org> 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.

Peter Eisentraut [2009-04-10 14:56 +0300]:

I assume the server has the snakeoil certificate installed?

It is a self-signed certificate indeed (Debian's ssl-cert package).

In that case, it is correct that the client refuses to proceed,
although the exact manner of breaking could perhaps be improved.

That may be true for 8.4, and I'm could stop configuring the snakeoil
certificate by default. That would make configuring a server for a
real SSL certificate harder than it needs to be, though.

However, we can't afford to break existing installations. If a user
has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he
could not connect to a remote SSL 8.3 cluster any more. So the check
needs at least be turned into a warning for connecting to a pre-8.4
server.

Also, the error message needs to be much clearer. Right now it just
tells you that it couldn't find a per-user root.crt and fails. So as
an user, I wonder: What is that file? I don't have one, where should I
get it from? And why does each user need to have its own?

html/libpq-ssl.html describes it fairly well:

"When the sslverify parameter is set to cn or cert, libpq will
verify that the server certificate is trustworthy by checking the
certificate chain up to a CA. For this to work, place the
certificate of a trusted CA in the file ~/.postgresql/root.crt in
the user's home directory. libpq will then verify that the server's
certificate is signed by one of the trusted certificate
authorities."

Nowhere does it say that the connection will fail immediately if you
do not have a root.crt. man psql(1) does not have any word about it,
like how to set the sslverify argument.

I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?

Thanks for considering,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin Pitt <mpitt@debian.org> writes:

I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?

I think I agree with Martin on this. The server doesn't fail if you
don't provide it a root cert; it just doesn't try to trace client certs
to the root. It is not apparent why the client should be stricter than
that, and definitely not apparent why such strictness should be the
default behavior.

regards, tom lane

Tom Lane wrote:

Martin Pitt <mpitt@debian.org> writes:

I do see the benefit of failing to connect to an SSL-enabled server
*if* I have a root.crt which doesn't match. But why fail if I don't
have one?

I think I agree with Martin on this. The server doesn't fail if you
don't provide it a root cert; it just doesn't try to trace client certs
to the root. It is not apparent why the client should be stricter than
that, and definitely not apparent why such strictness should be the
default behavior.

It's "secure by default". Without it, most people will *never* get
protected by verifying the certificate because they will not manually
copy root certificates there. And it would open up a big window for
making a very simple mistake (file missing or wrong name) that would
then silently disable SSL verification completely.

Arguably it's a bug to silently install a snakeoil cert by default. But
I realize that you have issues with backwards compatibility. How about
changing it so it points PGSSLROOTCERT to a system wide location that
holds the root.crt file? The user can then override this if proper
verification of a real certificate is wanted.

(you could also disable certificate verification by setting
PGSSLVERIFY=none, but that seems like a much worse fix)

//Mangus

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

It is not apparent why the client should be stricter than
that, and definitely not apparent why such strictness should be the
default behavior.

It's "secure by default".

In my experience ssh itself isn't this strict. Why should libpq be?
I think most users will see this as a bug, not as being secure.

regards, tom lane

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

It is not apparent why the client should be stricter than
that, and definitely not apparent why such strictness should be the
default behavior.

It's "secure by default".

In my experience ssh itself isn't this strict. Why should libpq be?
I think most users will see this as a bug, not as being secure.

ssh prompts the user when this happens. We don't have a mechanism for
prompting the user.

IIRC when you run ssh in a mode where it can't prompt the user, it will
refuse to connect, thus being just as strict as we are.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

In my experience ssh itself isn't this strict. Why should libpq be?

ssh prompts the user when this happens. We don't have a mechanism for
prompting the user.

In the first place, I have never seen such a prompt, despite the fact
that I use ssh constantly to connect to machines that I know do not have
properly signed certificates. If there is such a prompt, it isn't the
default behavior. In the second place, unconditionally failing isn't a
particularly nice emulation of a prompting behavior.

Perhaps a suitable compromise is to have the failure message include
a hint about how to prevent the failure if you don't want it?

regards, tom lane

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

In my experience ssh itself isn't this strict. Why should libpq be?

ssh prompts the user when this happens. We don't have a mechanism for
prompting the user.

In the first place, I have never seen such a prompt, despite the fact
that I use ssh constantly to connect to machines that I know do not have
properly signed certificates. If there is such a prompt, it isn't the
default behavior. In the second place, unconditionally failing isn't a
particularly nice emulation of a prompting behavior.

*really*? Here's what I get as an example (after removing the trust):

ha@mha-laptop:~/.ssh$ ssh cvs.postgresql.org
The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be
established.
DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3.
Are you sure you want to continue connecting (yes/no)? ^C

Are you saying you're not getting that? I've got that (or similar) on
every single platform I recall having used...

ssh doesn't use certificates, actually, it uses known host keys. The
difference being that with certificates you trust the root and thereby
everything under it. For ssh, afaik, you need to trust each host
individually.

Perhaps a suitable compromise is to have the failure message include
a hint about how to prevent the failure if you don't want it?

That would definitely work for me.

//Magnus

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

In the first place, I have never seen such a prompt, despite the fact
that I use ssh constantly to connect to machines that I know do not have
properly signed certificates.

*really*? Here's what I get as an example (after removing the trust):

ha@mha-laptop:~/.ssh$ ssh cvs.postgresql.org
The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be
established.
DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3.
Are you sure you want to continue connecting (yes/no)? ^C

This simply tells you that the machine has a new key since last time you
talked to it. It doesn't have anything to do with whether the machine's
cert has been signed by anybody. It also doesn't prevent you from
operating without a root.crt file of your own.

regards, tom lane

Tom Lane wrote:

Magnus Hagander <magnus@hagander.net> writes:

Tom Lane wrote:

In the first place, I have never seen such a prompt, despite the fact
that I use ssh constantly to connect to machines that I know do not have
properly signed certificates.

*really*? Here's what I get as an example (after removing the trust):

ha@mha-laptop:~/.ssh$ ssh cvs.postgresql.org
The authenticity of host 'cvs.postgresql.org (217.196.146.206)' can't be
established.
DSA key fingerprint is 54:27:10:f3:48:0a:f0:b6:c3:14:79:7e:49:c0:75:f3.
Are you sure you want to continue connecting (yes/no)? ^C

This simply tells you that the machine has a new key since last time you
talked to it. It doesn't have anything to do with whether the machine's
cert has been signed by anybody. It also doesn't prevent you from
operating without a root.crt file of your own.

SSH doesn't have certificates. The trusted key is as close as you get.
You can compare it to ssl with *only* self-signed-certificate. Where it
prompts you to authenticate the fingerprint of said
self-signed-certificate.

They do it through a prompt. We do it through a file. But as long as you
in pg only deal with self-signed certs, the outcome is pretty much the same.

//Magnus

On Friday 10 April 2009 17:13:55 Martin Pitt wrote:

However, we can't afford to break existing installations. If a user
has 8.4 installed locally, he'll use libpq from 8.4, and suddenly he
could not connect to a remote SSL 8.3 cluster any more. So the check
needs at least be turned into a warning for connecting to a pre-8.4
server.

This is not a question of new client with old server. The new version of the
client has a more secure default that will possibly prevent it from connecting
to *any* server that is not adequately configured.

But it's a default, so the user can change it.

Consider the analogy that a new web browser comes out that verifies server
certificates (as of course all respectable browsers do nowadays) whereas the
previous version one didn't. The right fix there is certainly not to
downgrade this to a warning when connecting to an older web server.

Not to mention the security implications: A rogue server could simply pretend
to be of an older version to circumvent the client's security check.

* Tom Lane (tgl@sss.pgh.pa.us) wrote:

I think I agree with Martin on this. The server doesn't fail if you
don't provide it a root cert; it just doesn't try to trace client certs
to the root. It is not apparent why the client should be stricter than
that, and definitely not apparent why such strictness should be the
default behavior.

I agree with this. Avoiding spoofing is good, but so is on the wire
encryption even if you don't have anti-spoofing. This is a reasonable
set-up and we shouldn't just fail on it.

Stephen

* Peter Eisentraut (peter_e@gmx.net) wrote:

This is not a question of new client with old server. The new version of the
client has a more secure default that will possibly prevent it from connecting
to *any* server that is not adequately configured.

A properly configured server could cause a failure too unless the client
is *also* properly configured. Sure, it's good for people to do. No, I
don't think we should break things if people don't build out a whole PKI
for PG and configure all their certs correctly. It's pie-in-the-sky to
think everyone will do that, and in the end most will just say "SSL
breaks stuff, so we'll disable it" which certainly isn't better.

But it's a default, so the user can change it.

It should be the default to connect, maybe with a warning.

Consider the analogy that a new web browser comes out that verifies server
certificates (as of course all respectable browsers do nowadays) whereas the
previous version one didn't. The right fix there is certainly not to
downgrade this to a warning when connecting to an older web server.

Uh, no, the right fix is to have a warning/prompt (as pretty much all
web browsers today do) but then continue to connect. Also, the
web-browser analogy completely falls apart when you consider that the
use case is significantly different (how many times have you connected
to a PG server that you didn't know?).

Thanks,

Stephen

Stephen Frost wrote:
-- Start of PGP signed section.

* Peter Eisentraut (peter_e@gmx.net) wrote:

This is not a question of new client with old server. The new version of the
client has a more secure default that will possibly prevent it from connecting
to *any* server that is not adequately configured.

A properly configured server could cause a failure too unless the client
is *also* properly configured. Sure, it's good for people to do. No, I
don't think we should break things if people don't build out a whole PKI
for PG and configure all their certs correctly. It's pie-in-the-sky to
think everyone will do that, and in the end most will just say "SSL
breaks stuff, so we'll disable it" which certainly isn't better.

But it's a default, so the user can change it.

It should be the default to connect, maybe with a warning.

Consider the analogy that a new web browser comes out that verifies server
certificates (as of course all respectable browsers do nowadays) whereas the
previous version one didn't. The right fix there is certainly not to
downgrade this to a warning when connecting to an older web server.

Uh, no, the right fix is to have a warning/prompt (as pretty much all
web browsers today do) but then continue to connect. Also, the
web-browser analogy completely falls apart when you consider that the
use case is significantly different (how many times have you connected
to a PG server that you didn't know?).

The problem is that libpq doesn't have any ability to warn/prompt like
SSH and web browsers do, so I think Magnus patterned the libpq behavior
around cases where warning/prompt failed in these environments.

I am not saying the current behavior is correct, only why it was
configured that way.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Friday 10 April 2009 21:27:54 Stephen Frost wrote:

I agree with this. Avoiding spoofing is good, but so is on the wire
encryption even if you don't have anti-spoofing. This is a reasonable
set-up and we shouldn't just fail on it.

This whole debate hinges on the argument that encryption without anti-spoofing
is *not* useful.

On Friday 10 April 2009 21:32:29 Stephen Frost wrote:

A properly configured server could cause a failure too unless the client
is *also* properly configured. Sure, it's good for people to do. No, I
don't think we should break things if people don't build out a whole PKI
for PG and configure all their certs correctly. It's pie-in-the-sky to
think everyone will do that, and in the end most will just say "SSL
breaks stuff, so we'll disable it" which certainly isn't better.

That's debatable. I think it's better.

But it's a default, so the user can change it.

It should be the default to connect, maybe with a warning.

If you connect with a warning, you have possibly already given up sensitive
information. That's no good.

Consider the analogy that a new web browser comes out that verifies
server certificates (as of course all respectable browsers do nowadays)
whereas the previous version one didn't. The right fix there is
certainly not to downgrade this to a warning when connecting to an older
web server.

Uh, no, the right fix is to have a warning/prompt (as pretty much all
web browsers today do) but then continue to connect.

Yes, this was under discussion a while ago but no one wanted to implement it.

Also, the
web-browser analogy completely falls apart when you consider that the
use case is significantly different (how many times have you connected
to a PG server that you didn't know?).

This is a fuzzy argument. What do you mean by "know", and how do you verify
what you "know" and whether what you "know" is correct? And why are you using
SSL at all if you think you "know" everything?

Peter Eisentraut <peter_e@gmx.net> writes:

On Friday 10 April 2009 21:27:54 Stephen Frost wrote:

I agree with this. Avoiding spoofing is good, but so is on the wire
encryption even if you don't have anti-spoofing. This is a reasonable
set-up and we shouldn't just fail on it.

This whole debate hinges on the argument that encryption without
anti-spoofing is *not* useful.

If we believe that then we need to also change the server to require
a root.crt. I do not believe it --- there is a significant difference
in the difficulty of passive listening and active spoofing.

regards, tom lane