Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > > 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 the numeric model provides four modes (refuse ssl, prefer no ssl,
> prefer ssl, require ssl) whereas the refuse/require combination only
> provides three modes (refuse ssl, require ssl, and one other depending on
> how you define it when neither is set). If you don't like numbers, make
> them words.
OK, that works:
require
prevent
prefer
noprefer
This allows us to subsume PGREQUIRE_SSL into the new variable. Do we
still need additional functionality in pg_hba.conf? I am only asking if
pushing these decisions out to the client makes sense?
For performance reasons, it is good to push this information out to the
clients so the proper connection method is used the first time.
However, for easier maintenance, we could have all of this in
pg_hba.conf only, and have clients try SSL first, and fall back to
non-SSL if the server doesn't want SSL. It would require two new
pg_hba.conf line types. We have prefer-SSL (host) and SSL-only (ssl)
now.
require (ssl)
prevent (nossl)
prefer (hostpreferssl)
noprefer(host)
This would change 'host' to not prefer SSL.
--
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
