Re: libpq compression

On Jun20, 2012, at 22:40 , Marko Kreen wrote:
> On Wed, Jun 20, 2012 at 10:05 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> I'm starting to think that relying on SSL/TLS for compression of
>> unencrypted connections might not be such a good idea after all. We'd
>> be using the protocol in a way it quite clearly never was intended to
>> be used...
>
> Maybe, but what is the argument that we should avoid
> on encryption+compression at the same time?

Mostly orthogonality, I think. I personally could live supporting
compression only together with encryption. We *shouldn't* require people
to create an RSA certificate just to use compression, though. I guess we
could do that by using one of the cipher suits that use Diffie-Hellman
key exchange (TLS_DH_anon_WITH_AES_128_CBC_SHA for example), but that
again requires fiddling with the allowed ciphers list. Or we could
auto-generate a self-signed RSA certificate if none is available. Which
is doable as long as we're going to stick with OpenSSL or GnuTLS, but if
we eventually want to support more SSL libraries server-side, this could
be a road blocker...

> AES is quite lightweight compared to compression, so should
> be no problem in situations where you care about compression.

Hm, yeah, that's especially true since DEFLATE (zlib) seems to be the
only universally supported compression method for TLS, which is rather
slow anyway (At least compared to alternatives such as LZO or Google's
Snappy).

> So what exactly is the situation we need to solve
> with postgres-specific protocol compression?

All we really want IMHO is a way to enable compression which requires
no more than specifying compress=on or the like in the connection
string. The million dollar question is, what is the easiest way to
get there? I initially though that relying on TLS for compression should
be relatively straight-forward, but it's starting to look rather messy…

best regards,
Florian Pflug