Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 739DFE0C96B for ; Sat, 16 Jun 2012 12:15:54 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1Sfuj9-0006Yi-Kq for pgsql-hackers@postgresql.org; Sat, 16 Jun 2012 15:15:53 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id q5GFFUvB019805; Sat, 16 Jun 2012 11:15:31 -0400 (EDT) From: Tom Lane To: Magnus Hagander cc: Euler Taveira , Florian Pflug , Bruce Momjian , Pgsql Hackers Subject: Re: libpq compression In-reply-to: References: <4FD9698F.2090407@timbira.com> <29853.1339651170@sss.pgh.pa.us> <4FD9E70B.9040607@timbira.com> <11502.1339699384@sss.pgh.pa.us> <20120615021938.GA21704@momjian.us> <22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org> <4FDB954F.9010606@timbira.com> <5136.1339799120@sss.pgh.pa.us> <5365.1339799869@sss.pgh.pa.us> <11357.1339822502@sss.pgh.pa.us> Comments: In-reply-to Magnus Hagander message dated "Sat, 16 Jun 2012 14:11:25 +0800" Date: Sat, 16 Jun 2012 11:15:30 -0400 Message-ID: <19804.1339859730@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/794 X-Sequence-Number: 209634 Magnus Hagander writes: > On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane 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