Re: Refuse SSL patch

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.

> > 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.

Jon