On Fri, Aug 19, 2016 at 09:22:32AM -0700, Jeff Janes wrote:
> On Sat, Jul 30, 2016 at 11:18 AM, Bruce Momjian wrote:
>
> On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote:
> > On 7/29/16 11:13 AM, Bruce Momjian wrote:
> > > Yes, I am thinking of a case where Postgres is
On Sat, Jul 30, 2016 at 11:18 AM, Bruce Momjian wrote:
> On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote:
> > On 7/29/16 11:13 AM, Bruce Momjian wrote:
> > > Yes, I am thinking of a case where Postgres is down but a malevolent
> > > user starts a Postgres server on 5432 to gather
On Fri, Jul 29, 2016 at 11:27:06AM -0400, Peter Eisentraut wrote:
> On 7/29/16 11:13 AM, Bruce Momjian wrote:
> > Yes, I am thinking of a case where Postgres is down but a malevolent
> > user starts a Postgres server on 5432 to gather passwords. Verifying
> > against an SSL certificate would avoid
On Fri, Jul 29, 2016 at 4:13 PM, Bruce Momjian wrote:
> Yes, I am thinking of a case where Postgres is down but a malevolent
> user starts a Postgres server on 5432 to gather passwords.
Or someone spoofs your DNS lookup, which is an attack that can
actually be done remotely in some cases.
For wh
On 7/29/16 11:13 AM, Bruce Momjian wrote:
> Yes, I am thinking of a case where Postgres is down but a malevolent
> user starts a Postgres server on 5432 to gather passwords. Verifying
> against an SSL certificate would avoid this problem, so there is some
> value in using SSL on localhost. (There
On Tue, Jul 19, 2016 at 03:24:26PM -0400, Peter Eisentraut wrote:
> On 7/19/16 10:00 AM, Magnus Hagander wrote:
> > What could actually be useful there is to explicitly put hostnossl on
> > the localhost entries. With the current defaults on the clients, that
> > wouldn't break anything, and it wou
On 7/20/16 8:55 AM, Daniel Verite wrote:
> Personally I think that TLS for local networking is wrong as a default, and
> it's unfortunate that distros like Debian/Ubuntu end up using that.
There is something to that, but I'm not sure that just giving up and
disabling SSL in the default configurati
Magnus Hagander wrote:
> > I don't understand why you want to change the default. Is it for
> > performance? Has it been measured?
> >
> >
> Yes. I've run into it multiple times, but I haven't specifically measured
> it. But I've had more than one situation where turning it off has
> com
On Tue, Jul 19, 2016 at 10:57 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 7/19/16 3:32 PM, Magnus Hagander wrote:
> > There are definitely cases where it's useful. I'm only arguing for
> > changing the default.
>
> I don't understand why you want to change the default. Is
Iirc we changed the default to be SSL for localhost to address a particular
problem. It seemed surprising at the time but it was the most effective
solution.
On 19 Jul 2016 21:58, "Peter Eisentraut"
wrote:
> On 7/19/16 3:32 PM, Magnus Hagander wrote:
> > There are definitely cases where it's usef
On 7/19/16 3:32 PM, Magnus Hagander wrote:
> There are definitely cases where it's useful. I'm only arguing for
> changing the default.
I don't understand why you want to change the default. Is it for
performance? Has it been measured?
--
Peter Eisentraut http://www.2ndQuadrant.c
On Tue, Jul 19, 2016 at 9:24 PM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 7/19/16 10:00 AM, Magnus Hagander wrote:
> > What could actually be useful there is to explicitly put hostnossl on
> > the localhost entries. With the current defaults on the clients, that
> > wouldn'
On 7/19/16 10:00 AM, Magnus Hagander wrote:
> What could actually be useful there is to explicitly put hostnossl on
> the localhost entries. With the current defaults on the clients, that
> wouldn't break anything, and it would leave people without the
> performance issues that you run into in the
On Tue, Jul 19, 2016 at 8:53 PM, Christoph Berg wrote:
> Makes sense. Is this something that should be implemented in postgresql,
> or via pg_createcluster?
>
>
Personally I'd like to see pg_createcluster et al mimic upstream as close
as possible, so I'd advocate these changes being made upstream
Makes sense. Is this something that should be implemented in postgresql, or via
pg_createcluster?
Am 19. Juli 2016 16:00:05 MESZ, schrieb Magnus Hagander :
>On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg
>wrote:
>
>> Re: Peter Eisentraut 2016-07-17 <
>> d6b22200-0e65-d17e-b227-b63d81720...@2nd
On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg wrote:
> Re: Peter Eisentraut 2016-07-17 <
> d6b22200-0e65-d17e-b227-b63d81720...@2ndquadrant.com>
> > On 7/15/16 3:07 PM, Andrew Dunstan wrote:
> > > Do those packagers who install dummy certificates and turn SSL on also
> > > change their pg_hba.
Re: Peter Eisentraut 2016-07-17
> On 7/15/16 3:07 PM, Andrew Dunstan wrote:
> > Do those packagers who install dummy certificates and turn SSL on also
> > change their pg_hba.conf.sample files to use hostssl?. That could go a
> > long way towards encouraging people.
>
> Debian, which I guess s
On 7/15/16 3:07 PM, Andrew Dunstan wrote:
> Do those packagers who install dummy certificates and turn SSL on also
> change their pg_hba.conf.sample files to use hostssl?. That could go a
> long way towards encouraging people.
Debian, which I guess sort of started this, does not, but there are
a
On 7/15/16 4:14 AM, Magnus Hagander wrote:
> The entire "prefer" mode is a design flaw, that we unfortunately picked
> as default mode.
>
> If it fails *for any reason*, it falls back to plaintext. Thus, you have
> to assume it will make a plaintext connection. Thus, it gives you zero
> guarantees
On Fri, Jul 15, 2016 at 4:14 AM, Magnus Hagander wrote:
>> The original complaint was not actually that "prefer" is a bad default,
>> but that in the presence of a root certificate on the client, a
>> certificate validation failure falls back to plain text. That seems
>> like a design flaw of the
On 07/15/2016 09:55 AM, Tom Lane wrote:
I'm inclined to think that a better answer than changing libpq's behavior
is to encourage DBAs to specify "hostssl" in pg_hba.conf for all external
connections.
Do those packagers who install dummy certificates and turn SSL on also
change their p
Magnus Hagander writes:
> The entire "prefer" mode is a design flaw, that we unfortunately picked as
> default mode.
> ...
> If you care about encryption, you should pick something else
> (require/verify). If you don't care about encryption, you should pick
> something else (allow, probably) so as
On 14.07.2016 23:34, Magnus Hagander wrote:
On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane mailto:t...@sss.pgh.pa.us>> wrote:
Greg Stark mailto:st...@mit.edu>> writes:
> Well what's required to "configure SSL" anyways? If you don't have
> verify-ca set or a root canal cert present then
On Fri, Jul 15, 2016 at 5:10 AM, Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 7/13/16 4:11 PM, Robert Haas wrote:
> > On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander
> wrote:
> >> You would think so.
> >>
> >> The default mode of "prefer" is ridiculous in a lot of ways. If yo
On 7/13/16 4:11 PM, Robert Haas wrote:
> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
>> You would think so.
>>
>> The default mode of "prefer" is ridiculous in a lot of ways. If you are
>> using SSL in any shape or form you should simply not use "prefer". That's
>> really the only answ
Magnus Hagander writes:
> On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane wrote:
>> Also, we could offer a switch to turn it off if necessary, with the
>> understanding that non-Unix-socket connections can be expected to fail
>> if user doesn't install a cert.
> If we do it we should also ensure it's
On Thu, Jul 14, 2016 at 11:27 PM, Tom Lane wrote:
> Greg Stark writes:
> > Well what's required to "configure SSL" anyways? If you don't have
> > verify-ca set or a root canal cert present then the server just needs a
> > certificate -- any certificate. Can the server just cons one up on demand
Greg Stark writes:
> Well what's required to "configure SSL" anyways? If you don't have
> verify-ca set or a root canal cert present then the server just needs a
> certificate -- any certificate. Can the server just cons one up on demand
> (or server startup or initdb)?
Hmm, good old "snake oil c
On 13 Jul 2016 9:28 pm, "Tom Lane" wrote:
>
> Robert Haas writes:
> > On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> Suppose we changed the default to "require". How crazy would that be?
>
> >> You mean, aside from the fact that it breaks every single installat
Robert Haas writes:
> On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Suppose we changed the default to "require". How crazy would that be?
>> You mean, aside from the fact that it breaks every single installation
>> that hasn't configured with SSL?
> No, including
Robert Haas writes:
> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
>> The default mode of "prefer" is ridiculous in a lot of ways. If you are
>> using SSL in any shape or form you should simply not use "prefer". That's
>> really the only answer at this point, unfortunately.
> Suppose
On Wed, Jul 13, 2016 at 3:16 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
>>> The default mode of "prefer" is ridiculous in a lot of ways. If you are
>>> using SSL in any shape or form you should simply not use "prefer". That's
>>> really t
On Thu, Jun 16, 2016 at 3:42 AM, Magnus Hagander wrote:
> You would think so.
>
> The default mode of "prefer" is ridiculous in a lot of ways. If you are
> using SSL in any shape or form you should simply not use "prefer". That's
> really the only answer at this point, unfortunately.
Suppose we c
On Thu, Jun 23, 2016 at 1:50 AM, Bruce Momjian wrote:
> On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote:
> > However, if this is the expected behavior, the documentation
> at https://
> > www.postgresql.org/docs/current/static/libpq-ssl.html should be
> updated to
> >
On Thu, Jun 16, 2016 at 10:42:56AM +0200, Magnus Hagander wrote:
> However, if this is the expected behavior, the documentation at https://
> www.postgresql.org/docs/current/static/libpq-ssl.html should be updated to
> make this more clear. It should be made clear that the existence of
On Thu, Jun 16, 2016 at 10:39 AM, Jakob Egger wrote:
> Hi!
>
> I've looked at the way libpq handles TLS certificates and plaintext
> fallback, and I am somewhat surprised.
>
> The default ssmode is prefer. According to the documentation, this will
> make libpq use an SSL connection if possible, b
Hi!
I've looked at the way libpq handles TLS certificates and plaintext fallback,
and I am somewhat surprised.
The default ssmode is prefer. According to the documentation, this will make
libpq use an SSL connection if possible, but will use a plain text connection
as a fallback. The certifica
37 matches
Mail list logo
