From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Euler Taveira <euler(at)timbira(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq compression |
Date: | 2012-06-17 10:54:10 |
Message-ID: | CABUevExq95H2ejYOCCLtTrLz0xCR_WU8Rq9eg0cOQ5Aj1xp_5g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 16, 2012 at 11:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
That seems reasonable. In looking at our current defaults, two things hit me:
Is there a reason why we don't have a parameter on the client
mirroring ssl_ciphers?
and
Shouldn't our default SSL methods include !aNULL, meaning by default
we exclude all ciphers that don't provide authentication (which means
they can be man-in-the-middle'd). AFACIT, eNULL/NULL is disabled by
default unless explicitly enabled, but aNULL isn't..
I don't think it matters from a pure security perspective since we
look inside the actual cert anyway (which shouldn't work with these
methods, I think), but it seems like a wrong default.
That, or just have DEFAULT as being the default (which in current
openssl means ALL:!aNULL:!eNULL.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2012-06-17 11:07:25 | Re: [patch] libpq one-row-at-a-time API |
Previous Message | Simon Riggs | 2012-06-17 10:48:30 | Re: Broken system timekeeping breaks the stats collector |