On Sat, Jun 16, 2012 at 6:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Euler Taveira <euler@timbira.com> writes:
>>> I see the point in not adding another dependencies or reinventing the wheel
>>> but I see more drawbacks than benefits in adopting a SSL-based compression.
>
>> In the end, judging this tradeoff is a matter of opinion, but I come to
>> the opposite conclusion.
>
> BTW, there is an additional technical argument that I don't think has
> been made yet. Assume that we implement our own transport compression,
> and then somebody runs an SSL connection using a recent OpenSSL version
> (in which, IIRC, SSL-level compression is enabled by default). Now,
> OpenSSL is trying to compress already-compressed data. That's not
> merely a waste of cycles but is very likely to be counterproductive,
> ie recompressed data usually gets larger not smaller.
>
> We could possibly address this by adding control logic to tell OpenSSL
> not to compress ... but that's almost exactly the code you don't want
> to write, just making a different option selection. And I wonder
> whether SSL implementations that don't support compression will accept
> a set-the-compression-option call at all.
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.
Meaning we need to teach pg_hba to treat a connection with null
encryption as hostnossl, even if it's an openssl-backed connection,
and mirrored. And in libpq, we have to make sure that a requiressl
connection *does* fail even if we have ssl, when we're using null
encryption. 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". Which in the easiest
first look would require ssl_ciphers to be controllable from
pg_hba.conf - but that doesn't work since we don't get to pg_hba.conf
until after we've negotiated the SSL mode...
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.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
