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

Hello all,

I have been packaging cvs snapshots, and now 8.4 beta 1 for Debian
recently, and hammered on postgresql-common enough to make it work
with 8.4 now (some changed semantics, migration of obsolete/renamed
postgresql.conf settings, etc.). Almost all of the tests pass now, so
it's generally working great.

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?)

$ PGHOST=127.0.0.1 /usr/lib/postgresql/8.4/bin/psql -l
psql: root certificate file "/home/martin/.postgresql/root.crt" does not exist

Thank you!

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

Martin Pitt <mpitt(at)debian(dot)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(at)debian(dot)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(at)debian(dot)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(at)debian(dot)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(at)debian(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)hagander(dot)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(at)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(at)hagander(dot)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(at)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(at)hagander(dot)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(at)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(at)sss(dot)pgh(dot)pa(dot)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(at)gmx(dot)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(at)gmx(dot)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(at)momjian(dot)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(at)gmx(dot)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

On Friday 10 April 2009 22:44:44 Bruce Momjian wrote:
> 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.

Of course. But if we really wanted to, this is nothing that can't be solved
with callbacks or something like that.

On Friday 10 April 2009 21:32:29 Stephen Frost wrote:
> Uh, no, the right fix is to have a warning/prompt (as pretty much all
> web browsers today do) but then continue to connect.

On that matter, it is interesting to observe where web browsers are heading
today.

It used to be that web browsers said, "Cannot verify server certificate.
Continue? [Yes] [No]" and everyone clicked yes.

The new firefox just says "invalid certificate" and nothing else, and then
somewhere below there is a small link to "Add an exception" and you need a
total of four clicks to proceed. So that looks a lot like that they are
moving away from easily allowing unverifyable server certificates as well.

On Friday 10 April 2009 22:50:02 Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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.

That would make sense if the server required SSL in the first place. But the
default configuration of the server is to take anything. It would conceivably
be proper to require a stronger client authentication mechanism than "trust"
on hostssl lines. (This doesn't have to be SSL-based client authentication.)

But we ship the server with a wide-open client access policy. Do you want to
change that? I think not. But if packagers want to change that, by all means
set up something stronger.

> I do not believe it --- there is a significant difference
> in the difficulty of passive listening and active spoofing.

Sure, there is a difference. But what is it, and what percentage of users do
you think are affected by it and can judge the difference?

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Friday 10 April 2009 22:50:02 Tom Lane wrote:
>> I do not believe it --- there is a significant difference
>> in the difficulty of passive listening and active spoofing.

> Sure, there is a difference. But what is it, and what percentage of users do
> you think are affected by it and can judge the difference?

I don't know, and I don't wish to be forcing a decision about it on
users.

regards, tom lane

[ sorry for double reply, but I missed answering this point ]

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On Friday 10 April 2009 22:50:02 Tom Lane wrote:
>> If we believe that then we need to also change the server to require
>> a root.crt.

> That would make sense if the server required SSL in the first place. But the
> default configuration of the server is to take anything. It would conceivably
> be proper to require a stronger client authentication mechanism than "trust"
> on hostssl lines. (This doesn't have to be SSL-based client authentication.)

I guess I was insufficiently precise, because you seem to be responding
to a different point than I intended to make. What I should have said
was "change the server to require a root.crt in order to successfully
establish an SSL connection". Not that you have to have such a file
even if you don't care about SSL. But if we are going to enforce that
SSL implies verification on the client side, then surely it should
also imply that on the server side.

regards, tom lane

Tom Lane escreveu:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On Friday 10 April 2009 22:50:02 Tom Lane wrote:
>>> I do not believe it --- there is a significant difference
>>> in the difficulty of passive listening and active spoofing.
>
>> Sure, there is a difference. But what is it, and what percentage of users do
>> you think are affected by it and can judge the difference?
>
> I don't know, and I don't wish to be forcing a decision about it on
> users.
>
Why don't we follow Magnus suggestion?

HINT: you could disable certificate verification by setting
PGSSLVERIFY=none

--
Euler Taveira de Oliveira
http://www.timbira.com/

Peter Eisentraut [2009-04-10 22:46 +0300]:
> This whole debate hinges on the argument that encryption without anti-spoofing
> is *not* useful.

I don't disagree, but it is not *worse* than having no encryption at
all.

The reason why Debian/Ubuntu install a snakeoil SSL certificate and
configure all packages to use it by default is not because we think
that this default configuration is "secure" in any way. The reason is
that configuring it that way is that it becomes darn easy to make your
entire server with all daemons such as postgresql, postfix, dovecot,
etc. trusted by simply replacing that central certificate. You can
still configure individual services to use a different one.

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

Martin Pitt <mpitt(at)debian(dot)org> writes:
> The reason why Debian/Ubuntu install a snakeoil SSL certificate and
> configure all packages to use it by default is not because we think
> that this default configuration is "secure" in any way. The reason is
> that configuring it that way is that it becomes darn easy to make your
> entire server with all daemons such as postgresql, postfix, dovecot,
> etc. trusted by simply replacing that central certificate. You can
> still configure individual services to use a different one.

This seems a bit handwavy --- there's a difference between the machine's
own cert and what it thinks is a root cert. How do you deal with that?
If the root cert is real, how do you put in self-signed server certs?

regards, tom lane

Peter Eisentraut [2009-04-10 14:56 +0300]:
> 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.

Is it really refusing self-signed certificates? That would be strange.

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).

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

Magnus Hagander [2009-04-10 19:14 +0200]:
> 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.

The problem and fallacy with security is that if you make it too
tight, people will just disable it. I'd be the happiest man on the
world if the internet would stop using bad SSL certificates, and all
those browsers which try to educate the users about exceptions could
just refuse the site and do nothing. But unfortunately the world
doesn't work that way.

Similarly, my concern is that people would rather disable SSL than
trying to get all their db users to put a certificate into their home
directory (t least this should be configurable at the system-wide
level, like checking whether a cert in /etc/ssl/certs/* matches; or
making this more flexible to configure the default on a system level
at least.)

So the nice thing about a warning is that it will stay around and nag
people, instead of dragging them into a kneejerk reaction to "fix"
their systems which suddenly got "broken".

But thanks to everyone for chiming in. Initially I thought it was just
a subtle regression. Since it doesn't seem to be, I'll just adapt my
test suite if this is going to stay like it is right now. I'm still
concerned about the potential confusion, though.

Thanks,

Martin

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

Tom Lane [2009-04-10 19:01 -0400]:
> This seems a bit handwavy --- there's a difference between the machine's
> own cert and what it thinks is a root cert.

Sure.

> How do you deal with that? If the root cert is real, how do you put
> in self-signed server certs?

I'm afraid I don't understand. If an admin replaces the default
snakeoil cert with a real one which he got signed by a CA, then of
course he would replace the standard system SSL cert (which all the
servers default to, and which is initially the snakeoil one) with the
"good" certificate. I don't see a reason why an admin would replace a
self-signed cert with another self-signed cert?

Thanks,

Martin

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

Martin Pitt <mpitt(at)debian(dot)org> writes:
> Tom Lane [2009-04-10 19:01 -0400]:
>> How do you deal with that? If the root cert is real, how do you put
>> in self-signed server certs?

> I'm afraid I don't understand. If an admin replaces the default
> snakeoil cert with a real one which he got signed by a CA, then of
> course he would replace the standard system SSL cert (which all the
> servers default to, and which is initially the snakeoil one) with the
> "good" certificate. I don't see a reason why an admin would replace a
> self-signed cert with another self-signed cert?

What I'm wondering about, given your emphasis on system-wide certs,
is how you deal with the fact that some apps (like web browsers)
are going to need a "real" root certificate, but you also want to
have a self-signed certificate that isn't traceable to the real
root. This may just indicate my ignorance of standard SSL operating
procedures ...

regards, tom lane

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> 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.

I don't see it as debatable at all, but let's turn it around. If the
client hasn't been configured with a root cert to check against, it will
*always* fail. That's the *default*. Web browsers, on the other hand,
are configured with a whole slew of root CAs, many of which are
questionable at best.

> > > 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.

The same is true for the non-SSL case, except there also won't be
encryption. Again, when SSL starts to break things for people, they'll
disable it. I really don't see much value in trying to save the people
who are configuring their passwords into files on disk either. What do
you think they're going to do?

> > 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.

That's understandable, I'm not a fan of implementing something like this
in a library either.

> > 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?

Because SSL offers *encryption*, which is honestly what it's primairly
useful for out on the interwebs. And by 'know', what I'm referring to
primairly is the server's DNS being controlled by someone you
know/trust, and close enough to not be an issue. Perhaps put another
way, I've never even heard of someone trying to spoof a PG server
because people simply don't make them generally available to the world,
with good reason.

Breaking support for getting encryption by default just isn't justified.
We could disable non-SSL by default too because it'd be a more secure
default, but does that make sense?

PKI is something that takes real effort to put together and make work.
The web browser situation is about the worst possible implementation you
can have and is only questionably better than just having encryption.
People who care will take the effort to set it up correctly and use it.
Of course, people who care will gripe up and down that we don't have
support for client-certificate based authentication.

I spend a fair bit of effort setting up and using a Kerberos-based
infrastructure to deal with authentication (client and server). I'd
like clients to not break by default if I havn't also got a PKI set up
and configured on all the clients because it's overkill. All I really
need or want SSL in PG for is encryption. The same is going to be
true for anyone who sets up PG with Kerberos/GSSAPI/SSPI (uh, Windows
Active Directory, that rather popular system out there). Perhaps that
can be solved by using Kerberos encryption, but I don't think we've
implemented that yet (Magnus?).

Thanks,

Stephen

* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> The new firefox just says "invalid certificate" and nothing else, and then
> somewhere below there is a small link to "Add an exception" and you need a
> total of four clicks to proceed. So that looks a lot like that they are
> moving away from easily allowing unverifyable server certificates as well.

Yes, it's extremely obnoxious and hasn't actually changed anything. We
often use certificates at work for internal web sites that aren't signed
by the santified CAs simply because it's not worth it. That causes
problems for our users when they're going to sites that are about a
billion times less likely to have been cracked into than Joe's crab shop
out on the internet. Encouraging people to believe that the PKI that's
currently being used for the web is actually meaningful is really the
first mistake.

Stephen

Stephen Frost wrote:
> * Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
>
>> The new firefox just says "invalid certificate" and nothing else, and then
>> somewhere below there is a small link to "Add an exception" and you need a
>> total of four clicks to proceed. So that looks a lot like that they are
>> moving away from easily allowing unverifyable server certificates as well.
>>
>
> Yes, it's extremely obnoxious and hasn't actually changed anything. We
> often use certificates at work for internal web sites that aren't signed
> by the santified CAs simply because it's not worth it. That causes
> problems for our users when they're going to sites that are about a
> billion times less likely to have been cracked into than Joe's crab shop
> out on the internet. Encouraging people to believe that the PKI that's
> currently being used for the web is actually meaningful is really the
> first mistake.
>

for self-signed certs, you first create a rootca, you can import the
rootca public key/cert to your browser, by offering it as the proper
mime type (I forget the specifics), once accepted into your browser, the
browser will trust any certs created off that root, same as if they are
signed by any of the 'commercial' CAs.. of course, if you do this,
you need to keep your rootca private keys safe.

John R Pierce wrote:
> for self-signed certs, you first create a rootca, you can import the
> rootca public key/cert to your browser, by offering it as the proper
> mime type (I forget the specifics), once accepted into your browser,
> the browser will trust any certs created off that root, same as if
> they are signed by any of the 'commercial' CAs.. of course, if you
> do this, you need to keep your rootca private keys safe.

ok, I found my notes on this... you put your root-certificate.crt on a
webserver, and offer it via a link with mime-type application/x-x509-ca-cert

Martin Pitt wrote:
> Peter Eisentraut [2009-04-10 14:56 +0300]:
>> 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.
>
> Is it really refusing self-signed certificates? That would be strange.

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.

(This is, of course, not a security issue in itself, because you don't
copy the *key* over. Just as a FYI to those who thought it would be :-P)

> 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?

//Magnus

Martin Pitt wrote:
-- Start of PGP signed section.
> 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 noticed you didn't quote the next sentence:

The SSL connection will fail if the server does not present a trusted
certificate.

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":

When the sslverify parameter is set to cn or cert, libpq requires a
trustworthy server certificate by checking the certificate chain up to a
CA. To allow verification, place the certificate of a trusted CA in the
file ~/.postgresql/root.crt in the user's home directory. (On Microsoft
Windows the file is named %APPDATA%\postgresql\root.crt.) libpq will
then verify that the server's certificate is signed by one of the
trusted certificate authorities. The SSL connection will fail if the
server does not present a trusted certificate.

I will now look at improving the libpq error message.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Peter Eisentraut wrote:
> On Friday 10 April 2009 08:39:33 Martin Pitt wrote:
> > Tom Lane [2009-04-10 1:15 -0400]:
> > > Martin Pitt <mpitt(at)debian(dot)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.

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Martin Pitt wrote:
> 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 have digested this thread, and have done two things: improved the
documentation and posted a patch to make the error message clearer.

In terms of your suggestion about root.crt, I think sslverify != none
should error if it can't verify the server's certificate, whether the
root.crt file is there or not. If you are asking for sslverify, it
should do that or error, not ignore the setting if there is no root.crt
file. The only other approach would be to add an sslverify value of
'try' that tries only if root.crt exists.

A separate issue is if sslverify should default to 'cn'.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> In terms of your suggestion about root.crt, I think sslverify != none
> should error if it can't verify the server's certificate, whether the
> root.crt file is there or not. If you are asking for sslverify, it
> should do that or error, not ignore the setting if there is no root.crt
> file.

Fair enough.

> The only other approach would be to add an sslverify value of
> 'try' that tries only if root.crt exists.

+1 for adding a "try" setting (though I'm not sure if I like that name
or not). I don't think that we actually have any choice in the matter.
By the end of beta, we *will* have such a setting; the only question
in my mind is whether it will be default or not. That depends on
exactly how nasty the villagers become ...

regards, tom lane

Bruce Momjian wrote:
> Martin Pitt wrote:
>> 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 have digested this thread, and have done two things: improved the
> documentation and posted a patch to make the error message clearer.
>
> In terms of your suggestion about root.crt, I think sslverify != none
> should error if it can't verify the server's certificate, whether the
> root.crt file is there or not. If you are asking for sslverify, it
> should do that or error, not ignore the setting if there is no root.crt
> file. The only other approach would be to add an sslverify value of
> 'try' that tries only if root.crt exists.

Doesn't "try" make the whole check pretty pointless, and you can just
set it to "none" then?

The point is, you need to *know*. "try" makes no sense. If we want to be
sure it never fails to connect, we disable security by default - setting
sslverify to "none". For those who care about security, we document
clearly how to enable it, and make it very clear that we ship with this
part of the security system disabled by default.

(shipping in this way, btw, will be considered a bug by anybody in the
security community. But that's a different community than ours, and at
least there's a builtin way to fix it)

Inventing a switch that makes it more or less impossible to figure out
if you are going to be secure or not makes no sense. When dealing with
security, maybe is the same as no, and you have to *know*.

//Magnus

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>> In terms of your suggestion about root.crt, I think sslverify != none
>> should error if it can't verify the server's certificate, whether the
>> root.crt file is there or not. If you are asking for sslverify, it
>> should do that or error, not ignore the setting if there is no root.crt
>> file.
>
> Fair enough.
>
>> The only other approach would be to add an sslverify value of
>> 'try' that tries only if root.crt exists.
>
> +1 for adding a "try" setting (though I'm not sure if I like that name
> or not). I don't think that we actually have any choice in the matter.
> By the end of beta, we *will* have such a setting; the only question
> in my mind is whether it will be default or not. That depends on
> exactly how nasty the villagers become ...

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).

It's just a matter of if it's default or not.

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Bruce Momjian wrote:
>> The only other approach would be to add an sslverify value of
>> 'try' that tries only if root.crt exists.

> Doesn't "try" make the whole check pretty pointless, and you can just
> set it to "none" then?

Not at all. What it means is that you control whether to make the check
by putting the file there (or not). Which you have to do anyway, if you
want to make the check. All that the current definition of the setting
is accomplishing is forcing people to fool with their environment variables,
which is a pain in the neck to varying degrees depending on platform.

> Inventing a switch that makes it more or less impossible to figure out
> if you are going to be secure or not makes no sense. When dealing with
> security, maybe is the same as no, and you have to *know*.

I am of the opinion that sslverify should have these values:

off = never verify
on = verify if root.crt is present (default behavior)
force = verify, failing if root.crt is not present

and the people who actually want to be "sure they're secure" can set the
"force" value in their environment.

This is not measurably different in effect from the fact that we have
sslmode defaulting to "prefer" rather than "require". If you want to be
"sure you're secure" you need the latter setting, but I don't believe
there is even remotely a consensus for making that the default.

BTW, what in the world prompted us to use "cn" as an allowed value for
sslverify? It looks for all the world like a typo for "on".

regards, tom lane

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> The option is there already, it's called "none". That's what people are
> asking for -

No, that is NOT what people are asking for. Please stop attacking a
straw man. What people are asking for is that by default, whether to
make the check or not should depend on whether the necessary
configuration file has been provided.

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Bruce Momjian wrote:
>>> The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>
>> Doesn't "try" make the whole check pretty pointless, and you can just
>> set it to "none" then?
>
> Not at all. What it means is that you control whether to make the check
> by putting the file there (or not). Which you have to do anyway, if you
> want to make the check.

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.

> All that the current definition of the setting
> is accomplishing is forcing people to fool with their environment
variables,
> which is a pain in the neck to varying degrees depending on platform.

That, or un-breaking their environment.

>> Inventing a switch that makes it more or less impossible to figure out
>> if you are going to be secure or not makes no sense. When dealing with
>> security, maybe is the same as no, and you have to *know*.
>
> I am of the opinion that sslverify should have these values:
>
> off = never verify
> on = verify if root.crt is present (default behavior)
> force = verify, failing if root.crt is not present
>
> and the people who actually want to be "sure they're secure" can set the
> "force" value in their environment.

Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
something like "maybe" or "external" or "file". I'd find it very bad if
you can say "sslverify=on" and then *not* end up getting it because of
some external factor. That needs to be clear in the naming of the value
if we go down that path.

Plus you somehow need to overload it with the cn vs certificate only
part. The ability to not do full hostname verification has been
specifically asked for.

> This is not measurably different in effect from the fact that we have
> sslmode defaulting to "prefer" rather than "require". If you want to be
> "sure you're secure" you need the latter setting, but I don't believe
> there is even remotely a consensus for making that the default.

That's a whole mess in itself, really. Originally, we had SSL on or off.
If you set it to on, it required SSL. If you set it to off, it wouldn't
use SSL.

"sslmode=prefer" honestly makes no sense - if I don't care if it ends up
encrypted or not (which it means), then why not just run with SSL off
and not have to deal with the overhead?

> BTW, what in the world prompted us to use "cn" as an allowed value for
> sslverify? It looks for all the world like a typo for "on".

Eh, what would you call it? It enables verification of the cn field in
the certificate. Another option I considered was "full", but someone
said that was bad - can't recall if that was on-list or off ATM.

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
> something like "maybe" or "external" or "file". I'd find it very bad if
> you can say "sslverify=on" and then *not* end up getting it because of
> some external factor. That needs to be clear in the naming of the value
> if we go down that path.

I guess you didn't think through the implications of the sslmode
comment, but: this is all merest self-delusion. If a hostile server is
trying to fool you, all he needs to do is configure his pg_hba.conf to
accept your connection in non-SSL mode, and your super duper
guaranteed-to-work ssl verification doesn't do a thing.

So unless you think you can persuade us to change the default sslmode to
"require", you're wasting your time making the above argument.

>> BTW, what in the world prompted us to use "cn" as an allowed value for
>> sslverify? It looks for all the world like a typo for "on".

> Eh, what would you call it? It enables verification of the cn field in
> the certificate. Another option I considered was "full", but someone
> said that was bad - can't recall if that was on-list or off ATM.

I would call it "on", and put the hostname behavior control somewhere
else. Overloading a security-sensitive parameter's meaning isn't a
particularly safe design, eh? Especially with a value that people
can't even read correctly if their eyes are a bit bleary.

regards, tom lane

Magnus Hagander wrote:
> Bruce Momjian wrote:
>> Martin Pitt wrote:
>>> 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 have digested this thread, and have done two things: improved the
>> documentation and posted a patch to make the error message clearer.
>>
>> In terms of your suggestion about root.crt, I think sslverify != none
>> should error if it can't verify the server's certificate, whether the
>> root.crt file is there or not. If you are asking for sslverify, it
>> should do that or error, not ignore the setting if there is no root.crt
>> file. The only other approach would be to add an sslverify value of
>> 'try' that tries only if root.crt exists.
>
> Doesn't "try" make the whole check pretty pointless, and you can just
> set it to "none" then?

Yes the snapshot psqlodbc driver already set sslverify to none and can't
change it though it may be differnet from the expected behavior. It was
not so easy to implement because sslverify parameter is illegal for <=
8.3 libpq and the psqlodbc driver doesn't rely on environment variables
at all.

regards,
Hiroshi Inoue

Tom Lane wrote:
> I am of the opinion that sslverify should have these values:
>
> off = never verify
> on = verify if root.crt is present (default behavior)
> force = verify, failing if root.crt is not present
>
> and the people who actually want to be "sure they're secure" can set the
> "force" value in their environment.
>
> This is not measurably different in effect from the fact that we have
> sslmode defaulting to "prefer" rather than "require". If you want to be
> "sure you're secure" you need the latter setting, but I don't believe
> there is even remotely a consensus for making that the default.
>
> BTW, what in the world prompted us to use "cn" as an allowed value for
> sslverify? It looks for all the world like a typo for "on".

l1 and 0O where taken? ;-)

It would be nice if 'sslverify' mimicked 'sslmode', which has these
values:

disable
allow
prefer
require

I don't see how we could use 'allow', but 'disable', 'prefer', and
'require' seem to work for sslverify, like sslmode.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> It would be nice if 'sslverify' mimicked 'sslmode', which has these
> values:
>
> disable
> allow
> prefer
> require
>
> I don't see how we could use 'allow', but 'disable', 'prefer', and
> 'require' seem to work for sslverify, like sslmode.

OK, crazy idea --- we use the three-value mode for sslverify listed
above, but we have it default to the value of sslmode. So, when sslmode
is prefer (the default), sslverify is 'prefer'. When sslmode is
require, so is sslverify, and of course disable sets them both to
disable. This gives us good defaults (prefer), but auto-locks down the
system when sslmode is 'require'.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Uh, it's not "on" if it's not "on". I'd rather call them "off", "on" and
>> something like "maybe" or "external" or "file". I'd find it very bad if
>> you can say "sslverify=on" and then *not* end up getting it because of
>> some external factor. That needs to be clear in the naming of the value
>> if we go down that path.
>
> I guess you didn't think through the implications of the sslmode
> comment, but: this is all merest self-delusion. If a hostile server is
> trying to fool you, all he needs to do is configure his pg_hba.conf to
> accept your connection in non-SSL mode, and your super duper
> guaranteed-to-work ssl verification doesn't do a thing.
>
> So unless you think you can persuade us to change the default sslmode to
> "require", you're wasting your time making the above argument.

Huh?

When I want a secure connection, I set sslmode=require. The same way I
in a browser make sure I'm running with a https connection. When I have
done this, I expect to have the security of the https protocol. Not just
maybe half of it.

I agree the default shouldn't be "require", because that requires the
server to be configured wit hit. In the on/off scenario, the reasonable
default would be "off".

The same way that imho it would make more sense to have sslverify
default to "off" than to "maybe".

>>> BTW, what in the world prompted us to use "cn" as an allowed value for
>>> sslverify? It looks for all the world like a typo for "on".
>
>> Eh, what would you call it? It enables verification of the cn field in
>> the certificate. Another option I considered was "full", but someone
>> said that was bad - can't recall if that was on-list or off ATM.
>
> I would call it "on", and put the hostname behavior control somewhere
> else. Overloading a security-sensitive parameter's meaning isn't a
> particularly safe design, eh? Especially with a value that people
> can't even read correctly if their eyes are a bit bleary.

How is that overloading it? It says how far you want to take the
verification of the certificate. It's overloading if you try to squeeze
in the "try" or "maybe" or whatever it'd be called setting, but not
until then.

That said, I'd not object at all to changing it to on, but keeping the
ability to set it to "cert" as well - because that's a feature people
asked for, and that makes sense to use.

//Magnus

Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Bruce Momjian wrote:
>>> Martin Pitt wrote:
>>>> 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 have digested this thread, and have done two things: improved the
>>> documentation and posted a patch to make the error message clearer.
>>>
>>> In terms of your suggestion about root.crt, I think sslverify != none
>>> should error if it can't verify the server's certificate, whether the
>>> root.crt file is there or not. If you are asking for sslverify, it
>>> should do that or error, not ignore the setting if there is no root.crt
>>> file. The only other approach would be to add an sslverify value of
>>> 'try' that tries only if root.crt exists.
>>
>> Doesn't "try" make the whole check pretty pointless, and you can just
>> set it to "none" then?
>
> Yes the snapshot psqlodbc driver already set sslverify to none and can't
> change it though it may be differnet from the expected behavior. It was
> not so easy to implement because sslverify parameter is illegal for <=
> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables
> at all.

Whatever the default is, if you can't change the value I'd say that
makes the ODBC driver pretty darn broken. It would be equally broken if
it was set to the default and it wasn't possible to change it.

//Magnus

Bruce Momjian wrote:
> Bruce Momjian wrote:
>> It would be nice if 'sslverify' mimicked 'sslmode', which has these
>> values:
>>
>> disable
>> allow
>> prefer
>> require
>>
>> I don't see how we could use 'allow', but 'disable', 'prefer', and
>> 'require' seem to work for sslverify, like sslmode.
>
> OK, crazy idea --- we use the three-value mode for sslverify listed
> above, but we have it default to the value of sslmode. So, when sslmode
> is prefer (the default), sslverify is 'prefer'. When sslmode is
> require, so is sslverify, and of course disable sets them both to
> disable. This gives us good defaults (prefer), but auto-locks down the
> system when sslmode is 'require'.

This hides what the system does pretty darn well. sslverify=prefer -
what does that mean? It's far from clear.

Plus, I don't understand how the "verify certificate but not hostname"
fits into this, but that could be because I really don't understand what
they mean :-)

However, slaving the default to sslmode probably make sense. As long as
sslmode is not set to require, it doesn't make that much sense to verify
the certificate at all, so I can see that defaulting to "none" or "off"
or whatever in that case. I still think controlling it by an external
file is a bad thing, but if it's controlled by the same connection
string, it makes a lot more sense.

So I think +1 for different defaults based on sslmode, but -1 on the
strange naming. (not to say we can't fix the naming that's there now,
but this specific suggestion makes it worse)

/Magnus

On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
> "sslmode=prefer" honestly makes no sense - if I don't care if it ends up
> encrypted or not (which it means), then why not just run with SSL off
> and not have to deal with the overhead?

Perhaps a large part of the problem at hand is in fact that the default is
sslmode=prefer, which, if the server is set up with some snakeoil certificate,
causes all these cn verification problems, when the user really didn't care in
the first place.

Another thing is that not all combinations of sslmode and sslverify make
sense. If the user cares little about SSL ("allow", "prefer"), then insisting
on a verifyable certificate is pointless.

One random idea is to fold both of these settings into sslmode, with the
following progression:

disable, allow, prefer, require, require-cert, require-cn

And then set the default to "disable", because as you say "prefer" is pretty
silly. And then users can explictly choose which level of SSL-ness they want.

On 12 apr 2009, at 11.13, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:

> On Sunday 12 April 2009 01:58:26 Magnus Hagander wrote:
>> "sslmode=prefer" honestly makes no sense - if I don't care if it
>> ends up
>> encrypted or not (which it means), then why not just run with SSL off
>> and not have to deal with the overhead?
>
> Perhaps a large part of the problem at hand is in fact that the
> default is
> sslmode=prefer, which, if the server is set up with some snakeoil
> certificate,
> causes all these cn verification problems, when the user really
> didn't care in
> the first place.
>
> Another thing is that not all combinations of sslmode and sslverify
> make
> sense. If the user cares little about SSL ("allow", "prefer"), then
> insisting
> on a verifyable certificate is pointless.

Yeah, agreed.

> One random idea is to fold both of these settings into sslmode, with
> the
> following progression:
>
> disable, allow, prefer, require, require-cert, require-cn
>
> And then set the default to "disable", because as you say "prefer"
> is pretty
> silly. And then users can explictly choose which level of SSL-ness
> they want.

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.

And +1 for changing the default sslmode regardless of how we configure
ssl verification.

/Magnus

Magnus Hagander wrote:
> > One random idea is to fold both of these settings into sslmode, with
> > the
> > following progression:
> >
> > disable, allow, prefer, require, require-cert, require-cn
> >
> > And then set the default to "disable", because as you say "prefer"
> > is pretty
> > silly. And then users can explictly choose which level of SSL-ness
> > they want.
>
> 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.
>
> And +1 for changing the default sslmode regardless of how we configure
> ssl verification.

I like Peter's idea too. Having _three_ SSL settings is overkill, and I
like the idea of doing it with one parameter. As already pointed out,
it makes no sense to do server certificate verification unless the
sslmode is 'require', and having require-cert and require-cn are very
clear.

I disagree with Magnus that having two parameters is better --- I think
there is just too much risk of misconfiguration with two parameters.

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 am fine with changing the default sslmode.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Magnus Hagander wrote:
> Hiroshi Inoue wrote:
>> Magnus Hagander wrote:
>>> Bruce Momjian wrote:
>>>> Martin Pitt wrote:
>>>>> 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 have digested this thread, and have done two things: improved the
>>>> documentation and posted a patch to make the error message clearer.
>>>>
>>>> In terms of your suggestion about root.crt, I think sslverify != none
>>>> should error if it can't verify the server's certificate, whether the
>>>> root.crt file is there or not. If you are asking for sslverify, it
>>>> should do that or error, not ignore the setting if there is no root.crt
>>>> file. The only other approach would be to add an sslverify value of
>>>> 'try' that tries only if root.crt exists.
>>> Doesn't "try" make the whole check pretty pointless, and you can just
>>> set it to "none" then?
>> Yes the snapshot psqlodbc driver already set sslverify to none and can't
>> change it though it may be differnet from the expected behavior. It was
>> not so easy to implement because sslverify parameter is illegal for <=
>> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables
>> at all.
>
> Whatever the default is, if you can't change the value I'd say that
> makes the ODBC driver pretty darn broken. It would be equally broken if
> it was set to the default and it wasn't possible to change it.

The psqlodbc driver has its own development cycle and doesn't use new
core features at once usually. The problem is the default behavior about
sslverify is incompatible with the 8.3 libpq behavior and the driver had
to do something with it before 8.4 release. What the snapshot driver
actualy does is to simply hide the *sslverify* functionality.

regards,
Hiroshi Inoue

Bruce Momjian wrote:
> Magnus Hagander wrote:
>>> One random idea is to fold both of these settings into sslmode, with
>>> the
>>> following progression:
>>>
>>> disable, allow, prefer, require, require-cert, require-cn
>>>
>>> And then set the default to "disable", because as you say "prefer"
>>> is pretty
>>> silly. And then users can explictly choose which level of SSL-ness
>>> they want.
>> 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.
>>
>> And +1 for changing the default sslmode regardless of how we configure
>> ssl verification.
>
> I like Peter's idea too. Having _three_ SSL settings is overkill, and I
> like the idea of doing it with one parameter. As already pointed out,
> it makes no sense to do server certificate verification unless the
> sslmode is 'require', and having require-cert and require-cn are very
> clear.
>
> I disagree with Magnus that having two parameters is better --- I think
> there is just too much risk of misconfiguration with two parameters.

Very well. One important part of having that would be to enable it by
default when you do "require", but there are other ways to accomplish
that of course.

> 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)

//Magnus

Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> Magnus Hagander wrote:
>>>> Bruce Momjian wrote:
>>>>> Martin Pitt wrote:
>>>>>> 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 have digested this thread, and have done two things: improved the
>>>>> documentation and posted a patch to make the error message clearer.
>>>>>
>>>>> In terms of your suggestion about root.crt, I think sslverify != none
>>>>> should error if it can't verify the server's certificate, whether the
>>>>> root.crt file is there or not. If you are asking for sslverify, it
>>>>> should do that or error, not ignore the setting if there is no
>>>>> root.crt
>>>>> file. The only other approach would be to add an sslverify value of
>>>>> 'try' that tries only if root.crt exists.
>>>> Doesn't "try" make the whole check pretty pointless, and you can just
>>>> set it to "none" then?
>>> Yes the snapshot psqlodbc driver already set sslverify to none and can't
>>> change it though it may be differnet from the expected behavior. It was
>>> not so easy to implement because sslverify parameter is illegal for <=
>>> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables
>>> at all.
>>
>> Whatever the default is, if you can't change the value I'd say that
>> makes the ODBC driver pretty darn broken. It would be equally broken if
>> it was set to the default and it wasn't possible to change it.
>
> The psqlodbc driver has its own development cycle and doesn't use new
> core features at once usually. The problem is the default behavior about
> sslverify is incompatible with the 8.3 libpq behavior and the driver had
> to do something with it before 8.4 release. What the snapshot driver
> actualy does is to simply hide the *sslverify* functionality.

I thought you were talking about a release version. If it's just a
snapshot, that is of course Ok. My apologies.

Though it might be easier even in that case to use an environment
variable to override it - that way the user could still override the
ODBC driver if you just checked if the variable was present before you
set it.

//Magnus

Magnus Hagander wrote:
> Hiroshi Inoue wrote:
>> Magnus Hagander wrote:
>>> Hiroshi Inoue wrote:
>>>> Magnus Hagander wrote:
>>>>> Bruce Momjian wrote:
>>>>>> Martin Pitt wrote:
>>>>>>> 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 have digested this thread, and have done two things: improved the
>>>>>> documentation and posted a patch to make the error message clearer.
>>>>>>
>>>>>> In terms of your suggestion about root.crt, I think sslverify != none
>>>>>> should error if it can't verify the server's certificate, whether the
>>>>>> root.crt file is there or not. If you are asking for sslverify, it
>>>>>> should do that or error, not ignore the setting if there is no
>>>>>> root.crt
>>>>>> file. The only other approach would be to add an sslverify value of
>>>>>> 'try' that tries only if root.crt exists.
>>>>> Doesn't "try" make the whole check pretty pointless, and you can just
>>>>> set it to "none" then?
>>>> Yes the snapshot psqlodbc driver already set sslverify to none and can't
>>>> change it though it may be differnet from the expected behavior. It was
>>>> not so easy to implement because sslverify parameter is illegal for <=
>>>> 8.3 libpq and the psqlodbc driver doesn't rely on environment variables
>>>> at all.
>>> Whatever the default is, if you can't change the value I'd say that
>>> makes the ODBC driver pretty darn broken. It would be equally broken if
>>> it was set to the default and it wasn't possible to change it.
>> The psqlodbc driver has its own development cycle and doesn't use new
>> core features at once usually. The problem is the default behavior about
>> sslverify is incompatible with the 8.3 libpq behavior and the driver had
>> to do something with it before 8.4 release. What the snapshot driver
>> actualy does is to simply hide the *sslverify* functionality.
>
> I thought you were talking about a release version. If it's just a
> snapshot, that is of course Ok. My apologies.
>
> Though it might be easier even in that case to use an environment
> variable to override it - that way the user could still override the
> ODBC driver if you just checked if the variable was present before you
> set it.

Unfortnately enviornment variables are application wide and aren't
appropriate at all for the driver which should set the properties
on the fly per e.g. connection according to the DSN or the connection
string.

regards,
Hiroshi Inoue

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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On 14 apr 2009, at 04.33, Bruce Momjian <bruce(at)momjian(dot)us> 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"....

/Magnus

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)

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)

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/<myservername>.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)

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)

* Martin Pitt (mpitt(at)debian(dot)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

* Martin Pitt (mpitt(at)debian(dot)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/<myservername>.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

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)

Stephen Frost [2009-04-14 9:18 -0400]:
> * Martin Pitt (mpitt(at)debian(dot)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)

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.

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. ;-)

Magnus Hagander wrote:
> On 14 apr 2009, at 04.33, Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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 <mpitt(at)debian(dot)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.
>
> 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 <bruce(at)momjian(dot)us> 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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Magnus Hagander wrote:
>> On 14 apr 2009, at 04.33, Bruce Momjian <bruce(at)momjian(dot)us> 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.

Here's a patch for this. Obviously, a lot needs to be done about the
docs here, I'm working on that.

I went with the names "require", "verify-ca" and "verify-full".

Patch also changes the default from "prefer" to "disable", per discussion.

Comments?

//Magnus

On Monday 20 April 2009 11:19:04 Magnus Hagander wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> >> On 14 apr 2009, at 04.33, Bruce Momjian <bruce(at)momjian(dot)us> 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.
>
> Here's a patch for this. Obviously, a lot needs to be done about the
> docs here, I'm working on that.
>
> I went with the names "require", "verify-ca" and "verify-full".
>
> Patch also changes the default from "prefer" to "disable", per discussion.

Looks good to me.

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Patch also changes the default from "prefer" to "disable", per discussion.

I confess to not having paid attention to this thread for awhile.
I have to violently object to this conclusion --- it is throwing the
baby out with the bathwater. Under the pretense of being "secure by
default" it will in fact make things *less* secure. A minimum
requirement in my view is that existing configurations should continue
to work and be no less secure than before. Having a connection that
was encrypted in 8.3 silently become clear-text after installing 8.4
is just plain NOT acceptable.

I think the patch would be fine if we simply keep the default where
it is, however. Is there some point I am missing that compels
selection of a less-secure default?

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Patch also changes the default from "prefer" to "disable", per discussion.
>
> I confess to not having paid attention to this thread for awhile.
> I have to violently object to this conclusion --- it is throwing the
> baby out with the bathwater. Under the pretense of being "secure by
> default" it will in fact make things *less* secure. A minimum
> requirement in my view is that existing configurations should continue
> to work and be no less secure than before. Having a connection that
> was encrypted in 8.3 silently become clear-text after installing 8.4
> is just plain NOT acceptable.
>
> I think the patch would be fine if we simply keep the default where
> it is, however. Is there some point I am missing that compels
> selection of a less-secure default?

The current default *makes no sense*. Ever. Not just as a default.

However, I can see us having "allow" instead of "disable" as the
default. That is the most forgiving of all settings - it will work with
whatever you had configured before.

//Magnus

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Tom Lane wrote:
>> Having a connection that
>> was encrypted in 8.3 silently become clear-text after installing 8.4
>> is just plain NOT acceptable.
>>
>> I think the patch would be fine if we simply keep the default where
>> it is, however. Is there some point I am missing that compels
>> selection of a less-secure default?

> The current default *makes no sense*. Ever. Not just as a default.

I categorically reject that thinking. Encrypted connections are useful
even without authentication. Your argument ignores the real fact that
eavesdropping is easier than man-in-the-middle attacks. Even if there
weren't any significant difference, what is the gain from switching to
unencrypted in cases where we previously used encryption? There is
none.

> However, I can see us having "allow" instead of "disable" as the
> default. That is the most forgiving of all settings - it will work with
> whatever you had configured before.

And it still moves us to "less secure than 8.3 by default", because
configurations that formerly used encrypted connections might now use
unencrypted ones. It's not acceptable.

regards, tom lane

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Tom Lane wrote:
>>> Having a connection that
>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>> is just plain NOT acceptable.
>>>
>>> I think the patch would be fine if we simply keep the default where
>>> it is, however. Is there some point I am missing that compels
>>> selection of a less-secure default?
>
>> The current default *makes no sense*. Ever. Not just as a default.
>
> I categorically reject that thinking. Encrypted connections are useful
> even without authentication. Your argument ignores the real fact that
> eavesdropping is easier than man-in-the-middle attacks. Even if there
> weren't any significant difference, what is the gain from switching to
> unencrypted in cases where we previously used encryption? There is
> none.

Did you read the thread? That's not the argument that makes it make no
sense.

Yes, encrypted connections are useful without authentication. But they
are quite useless unless you can determine if you have encryption *at
all* before you start sending sensitive data.

>> However, I can see us having "allow" instead of "disable" as the
>> default. That is the most forgiving of all settings - it will work with
>> whatever you had configured before.
>
> And it still moves us to "less secure than 8.3 by default", because
> configurations that formerly used encrypted connections might now use
> unencrypted ones. It's not acceptable.

Fine. I'll leave the default as it is then, and document that the
default we've chosen means "I don't care if I get security or not, but
if possible, I'd like to pay the encryption overhead".

//Magnus

Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>> Tom Lane wrote:
>>>> Having a connection that
>>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>>> is just plain NOT acceptable.
>>>>
>>>> I think the patch would be fine if we simply keep the default where
>>>> it is, however. Is there some point I am missing that compels
>>>> selection of a less-secure default?
>>> The current default *makes no sense*. Ever. Not just as a default.
>> I categorically reject that thinking. Encrypted connections are useful
>> even without authentication. Your argument ignores the real fact that
>> eavesdropping is easier than man-in-the-middle attacks. Even if there
>> weren't any significant difference, what is the gain from switching to
>> unencrypted in cases where we previously used encryption? There is
>> none.
>
> Did you read the thread? That's not the argument that makes it make no
> sense.
>
> Yes, encrypted connections are useful without authentication. But they
> are quite useless unless you can determine if you have encryption *at
> all* before you start sending sensitive data.
>
>
>>> However, I can see us having "allow" instead of "disable" as the
>>> default. That is the most forgiving of all settings - it will work with
>>> whatever you had configured before.
>> And it still moves us to "less secure than 8.3 by default", because
>> configurations that formerly used encrypted connections might now use
>> unencrypted ones. It's not acceptable.
>
> Fine. I'll leave the default as it is then, and document that the
> default we've chosen means "I don't care if I get security or not, but
> if possible, I'd like to pay the encryption overhead".
>

I have applied a patch that does this.

There are some further documentation updates required, I'll keep working
on those.

//Magnus

Magnus Hagander wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>>>> Tom Lane wrote:
>>>>> Having a connection that
>>>>> was encrypted in 8.3 silently become clear-text after installing 8.4
>>>>> is just plain NOT acceptable.
>>>>>
>>>>> I think the patch would be fine if we simply keep the default where
>>>>> it is, however. Is there some point I am missing that compels
>>>>> selection of a less-secure default?
>>>> The current default *makes no sense*. Ever. Not just as a default.
>>> I categorically reject that thinking. Encrypted connections are useful
>>> even without authentication. Your argument ignores the real fact that
>>> eavesdropping is easier than man-in-the-middle attacks. Even if there
>>> weren't any significant difference, what is the gain from switching to
>>> unencrypted in cases where we previously used encryption? There is
>>> none.
>> Did you read the thread? That's not the argument that makes it make no
>> sense.
>>
>> Yes, encrypted connections are useful without authentication. But they
>> are quite useless unless you can determine if you have encryption *at
>> all* before you start sending sensitive data.
>>
>>
>>>> However, I can see us having "allow" instead of "disable" as the
>>>> default. That is the most forgiving of all settings - it will work with
>>>> whatever you had configured before.
>>> And it still moves us to "less secure than 8.3 by default", because
>>> configurations that formerly used encrypted connections might now use
>>> unencrypted ones. It's not acceptable.
>> Fine. I'll leave the default as it is then, and document that the
>> default we've chosen means "I don't care if I get security or not, but
>> if possible, I'd like to pay the encryption overhead".
>>
>
> I have applied a patch that does this.
>
> There are some further documentation updates required, I'll keep working
> on those.

I've committed another set of docs, which I think means I'm done.
Comments are welcome.

//Magnus