Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id ACBF1AD7E31 for ; Sun, 17 Jun 2012 13:30:15 -0300 (ADT) Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SgIMe-00073I-3b for pgsql-hackers@postgresql.org; Sun, 17 Jun 2012 16:30:14 +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 q5HGTruI027044; Sun, 17 Jun 2012 12:29:53 -0400 (EDT) From: Tom Lane To: Florian Pflug cc: Magnus Hagander , Euler Taveira , Bruce Momjian , Pgsql Hackers Subject: Re: libpq compression In-reply-to: <9B10BD6E-31AA-4699-BB67-5C386B623F77@phlo.org> 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> <19804.1339859730@sss.pgh.pa.us> <9B10BD6E-31AA-4699-BB67-5C386B623F77@phlo.org> Comments: In-reply-to Florian Pflug message dated "Sun, 17 Jun 2012 18:11:02 +0200" Date: Sun, 17 Jun 2012 12:29:53 -0400 Message-ID: <27043.1339950593@sss.pgh.pa.us> X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201206/840 X-Sequence-Number: 209680 Florian Pflug writes: > Would we still tell openssl to only negotiate ciphers in the configured > list of available ciphers + NULL? If not, what happens if a connection > happens to use a cipher that is actually stronger than any cipher on > the "list of acceptable ciphers" list? The DBA wouldn't necessarily be > aware that such a cipher even exists, since it could have been made > available by an openssl upgrade So? If the DBA has gone so far as to list specific ciphers, who are we to second guess his judgment? It's not for us to decide that cipher X is "stronger" than the ones he listed. > But if we restrict the negotiable ciphers to the configure list + NULL, > then we're good I think. The fly in the ointment with any of these ideas is that the "configure list" is not a list of exact cipher names, as per Magnus' comment that the current default includes tests like "!aNULL". I am not sure that we know how to evaluate such conditions if we are applying an after-the-fact check on the selected cipher. Does OpenSSL expose any API for evaluating whether a selected cipher meets such a test? regards, tom lane