On Sat, Jun 16, 2012 at 11:15:30AM -0400, Tom Lane wrote: > Magnus Hagander <mag...@hagander.net> writes: > > On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> It's not obvious to me that we actually *need* anything except the > >> ability to recognize that a null-encrypted SSL connection probably > >> shouldn't be treated as matching a hostssl line; which is not something > >> that requires any fundamental rearrangements, since it only requires an > >> after-the-fact check of what was selected. > > > Maybe I spelled it out wrong. It does require it insofar that if we > > want to use this for compression, we must *always* enable openssl on > > the connection. So the "with these encryption method" boils down to > > "NULL encryption only" or "whatever other standards I have for > > encryption". We don't need the ability to change the "whatever other > > standards" per subnet, but we need to control the > > accept-NULL-encryption on a per subnet basis. > > After sleeping on it, I wonder if we couldn't redefine the existing > "list of acceptable ciphers" option as the "list of ciphers that are > considered to provide encrypted transport". So you'd be allowed to > connect with SSL using any unapproved cipher (including NULL), the > backend just considers it as equivalent to a non-SSL connection for > pg_hba purposes. Then no change is needed in any configuration stuff. > > regards, tom lane >
+1 That is nice and clean. Regards, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
