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

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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: pgsql-bugs(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Martin Pitt <mpitt(at)debian(dot)org>
Subject: Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt
Date: 2009-04-10 20:11:10
Message-ID: 200904102311.11874.peter_e@gmx.net (view raw or flat)
Thread:
Lists: pgsql-bugs
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?

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-04-10 20:13:31
Subject: Re: libpq 8.4 beta1: $PGHOST complains about missing root.crt
Previous:From: Tom LaneDate: 2009-04-10 20:07:17
Subject: Re: Re: [BUGS] BUG #4027: backslash escapingnotdisabled inplpgsql

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