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: