From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Jon Jensen <jon(at)endpoint(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Refuse SSL patchf |
Date: | 2003-01-07 17:14:45 |
Message-ID: | 200301071714.h07HEjh24376@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Jon Jensen wrote:
> On Tue, 7 Jan 2003, Bruce Momjian wrote:
>
> > > The proposed SSLMODE is a client-side configuration option to supercede
> > > REQUIRESSL, which is also a client configuration option. Here's the
> > > problem:
> > >
> > > 1. The client always tries to connect via SSL if SSL support was compiled
> > > in. There is no way to change this presently.
> > > 2. If the server can do SSL *at all*, it negotiates an SSL connection with
> > > the client.
> >
> > Oh, that is a key thing I didn't know. Seems we should just add a libpq
> > PREVENTSSL option and be done with it.
>
> That's exactly what my original patch did! :)
>
> Tom thought that having conflicting REFUSESSL and REQUIRESSL directives
> would be confusing, and since I dug up someone's old discussion in the
> list archives of the four possible modes, we could move to that.
Oh. I find two params clearer than one with meaningless numbers. :-)
> > > But on the other hand, we want some control on the server as well -- we
> > > may want to disallow SSL connections from a certain IP address, if nothing
> > > else just to make sure a client doesn't accidentally use SSL over the
> > > local network because someone forgets not to use it. Otherwise we could be
> > > accidentally using SSL on the local network and killing performance. So I
> > > added a 'hostnossl' option to pg_hba.conf, which will allow only non-SSL
> > > connections from certain IP addresses.
> >
> > Perhaps your idea of 'hostnossl' in pg_hba.conf is a good one. That
> > way, both client and server would have the ability to say never or only
> > SSL. It allows more central control.
> >
> > So, in negotiation, that only leaves open the question of what happens
> > when none of those are set, and it seems we prefer SSL in such cases.
> > Is that the correct default?
> >
> > In fact, once we have 'hostnossl' why do we need PREVENTSSL in libpq?
>
> Because hostnossl is only an authentication control, not a connection
> control. libpq will *always* connect SSL if it can, which guarantees that
> the authentication will fail with hostnossl. We have to have configuration
> options on both ends to make this work.
Well, your 0-3 valued patch must have had some code that fell back to
non-SSL when SSL failed. Can't we do that by default?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-01-07 17:30:56 | Re: Docs for service file |
Previous Message | Jon Jensen | 2003-01-07 17:06:23 | Re: Refuse SSL patch |