Re: libpq compression
От | Magnus Hagander |
---|---|
Тема | Re: libpq compression |
Дата | |
Msg-id | CABUevExq95H2ejYOCCLtTrLz0xCR_WU8Rq9eg0cOQ5Aj1xp_5g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: libpq compression (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: libpq compression
|
Список | pgsql-hackers |
On Sat, Jun 16, 2012 at 11:15 PM, Tom Lane <tgl@sss.pgh.pa.us> 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. 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/
В списке pgsql-hackers по дате отправления: