Re: Refuse SSL patchf - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: Refuse SSL patchf
Date
Msg-id 200301071714.h07HEjh24376@candle.pha.pa.us
Whole thread Raw
In response to Re: Refuse SSL patch  (Jon Jensen <jon@endpoint.com>)
Responses Re: Refuse SSL patchf
List 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@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-patches by date:

Previous
From: Jon Jensen
Date:
Subject: Re: Refuse SSL patch
Next
From: Peter Eisentraut
Date:
Subject: Re: Docs for service file