Re: libpq compression - Mailing list pgsql-hackers

On Sat, Jun 16, 2012 at 12:55 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Yes, but there's also a lot of such awkward logic we need to add if we
>> *do* go with the SSL library doing the compression:
>
>> For example, we can no longer trust the SSL library to always do
>> encryption, since we specifically want to support null encryption.
>
> True, but are you sure we don't need to do that anyway?  What happens
> today, if a non-libpq client connects with SSL and specifies null
> encryption?

openssl rejects the connection unless you have explicitly allowed NULL
encryption in ssl_ciphers.

Which is the only sensible default.


>> And we currently have no way to specify different
>> encryption options on a per-host basis, which is something we'd have
>> to do (e.g. i want to be able to say that "subnet x requires
>> encryption with these encryptions methods" and "subnet y doesn't
>> require encryption but should do compression".
>
> [ shrug... ]  Having that sort of control over a homebrew compression
> solution will *also* require a lot of control logic that does not exist
> today.

The important part isn't really being able to control the compression
in this. It's that we're overloading a "convenience feature"
(compression) in the settings of a security feature (encryption).
Which leads to both complex processing, and also a fairly high risk of
accidentally configuring what you wouldn't want unless we change the
interface to make it look like separate things even if they aren't.


>> So there's quite a bit of complexity that needs to be put in there
>> just to deal with the fact that we're using SSL to do compression, if
>> we want to support it in a way that's not hackish.
>
> 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.  Things like "subnet x
> requires encryption with these encryption methods" are features that are
> sensible with our existing feature set.  But we don't have that now and
> nobody has asked for it, so I think you are moving the goalposts rather
> unfairly by claiming that a compression-related patch needs to add it.

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.

It also risks some level of information leak - assuming someone
connects with NULL encryption and we don't support it, unless we do
something particular about it, the error message will go out in
cleartext. Today, you will get a client generated error message and no
actual message crosses the wire in cleartext.

It's not that we can't deal with those things. It's just that it's
going to take some work, and some careful thought about exactly which
parts can be exposed over NULL encrypted connections.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/