On Sat, Jun 16, 2012 at 11:15:30AM -0400, Tom Lane wrote:
> 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
>
+1 That is nice and clean.
Regards,
Ken