Skip site navigation (1) Skip section navigation (2)

Re: [pgsql-hackers-win32] More SSL questions..

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,"T(dot)J(dot)" <tjtoocool(at)phreaker(dot)net>, pgsql-bugs(at)postgresql(dot)org,pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [pgsql-hackers-win32] More SSL questions..
Date: 2005-01-05 23:02:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers-win32
Tom Lane wrote:

> Basically my point here is that the default "prefer" SSL mode
> effectively becomes "require" if the server has a root.crt.

Ok, in the scenario where validation is important, clients should be 
using "require" anyway, so it's not an issue so long as libpq doesn't 
try to fall back to non-SSL when "require" is in effect.

A default SSL mode of "prefer" does seem a bit dodgy, though -- it only 
protects against passive attacks. I'd be tempted to make "disable" the 
default, so that you have a better chance of visible errors if clients 
are not correctly configured rather than silently forging ahead with a 
connection that might be unintentionally insecure. That would mean lots 
of pain for existing installs though :(

I had to dig into the libpq docs to find any mention of the environment 
variables / config files that set the SSL behaviour. It'd be useful to 
have details in the psql manpage too..


In response to

pgsql-bugs by date

Next:From: Hansjörg HerrboldDate: 2005-01-06 08:23:24
Subject: ODBC / startup and existing pidfile
Previous:From: Tom LaneDate: 2005-01-05 22:36:23
Subject: Re: [pgsql-hackers-win32] More SSL questions..

pgsql-hackers-win32 by date

Next:From: Bruce MomjianDate: 2005-01-05 23:16:08
Subject: Re: [BUGS] More SSL questions..
Previous:From: Andrew DunstanDate: 2005-01-05 22:39:59
Subject: Re: [BUGS] More SSL questions..

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group