pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
Cc: Euler Taveira <euler@timbira.com>
Cc: Florian Pflug <fgp@phlo.org>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Pgsql Hackers <pgsql-hackers@postgresql.org>
Subject: Re: libpq compression
Date: Sat, 16 Jun 2012 11:15:30 -0400
Message-ID: <19804.1339859730@sss.pgh.pa.us> (raw)
In-Reply-To: <CABUevEy1sUTOeCjNicUggnMpT7MfgjWud8kQ=wkvJsfbCU8=WQ@mail.gmail.com>
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>
	<CABUevEyv4T+1gR6_Uqm_1qUD9PNDg6UdXbJhwHZgFi9hpQQ6NQ@mail.gmail.com>
	<F3B8BAA6-23E9-423A-A7D1-D2E14769F326@phlo.org>
	<CABUevExi-cJ6AvF2kDOy+qQsB+0JHofrcvVmNVoJ2HziZMMaAg@mail.gmail.com>
	<22690C61-E960-4A2A-BFD5-DAD3D3B5C474@phlo.org>
	<CABUevEzVpqS5RCLz2fFREdPFkuYkEKsrMpnfPixYWPki2=iJOA@mail.gmail.com>
	<4FDB954F.9010606@timbira.com>
	<5136.1339799120@sss.pgh.pa.us>
	<5365.1339799869@sss.pgh.pa.us>
	<CABUevEz_V4YYc0tUhkC6KD2GddysM5Z76pcHcMYiMDd7dwMxVQ@mail.gmail.com>
	<11357.1339822502@sss.pgh.pa.us>
	<CABUevEy1sUTOeCjNicUggnMpT7MfgjWud8kQ=wkvJsfbCU8=WQ@mail.gmail.com>

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



view thread (289+ messages)  latest in thread

Message-ID: <19804.1339859730@sss.pgh.pa.us>
Permalink:  ../19804.1339859730@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/19804.1339859730@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, magnus@hagander.net, euler@timbira.com, fgp@phlo.org, bruce@momjian.us
  Subject: Re: libpq compression
  In-Reply-To: <19804.1339859730@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox