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

* 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