Magnus Hagander <magnus@hagander.net> writes:
> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane <tgl@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
