Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt - Mailing list pgsql-bugs
From | Stephen Frost |
---|---|
Subject | Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt |
Date | |
Msg-id | 20090411013946.GH8123@tamriel.snowman.net Whole thread Raw |
In response to | Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-bugs |
* Peter Eisentraut (peter_e@gmx.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. >=20 > 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. >=20 > If you connect with a warning, you have possibly already given up sensiti= ve=20 > 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. >=20 > 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?). >=20 > This is a fuzzy argument. What do you mean by "know", and how do you ver= ify=20 > what you "know" and whether what you "know" is correct? And why are you = using=20 > 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
pgsql-bugs by date: