Re: Compression on SSL links?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: Karl Denninger <karl(at)denninger(dot)net>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Compression on SSL links?
Date: 2010-08-13 14:50:41
Message-ID: 201008131450.o7DEofQ00761@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Craig Ringer wrote:
> On 13/08/2010 9:31 PM, Bruce Momjian wrote:
> > Karl Denninger wrote:
> >> I may be blind - I don't see a way to enable this. OpenSSL "kinda"
> >> supports this - does Postgres' SSL connectivity allow it to be
> >> supported/enabled?
> >
> > What are you asking, exactly?
>
> As far as I can tell they're asking for transport-level compression,
> using gzip or similar, in much the same way as SSL/TLS currently
> provides transport-level encryption. Compression at the postgresql
> protocol level or above, so it's invisible at the level of the libpq
> APIs for executing statements and processing results, and doesn't change
> SQL processing.
>
> Since remote access is often combined with SSL, which is already
> supported by libpq, using SSL-integrated compression seems pretty
> promising if it's viable in practice. It'd avoid the pain of having to
> add compression to the Pg protocol by putting it "outside" the current
> protocol, in the SSL layer. Even better, compressing results before
> encrypting them makes the encrypted traffic *much* stronger against
> known-plaintext and pattern-based attacks. And, of course, compressing
> the content costs CPU time but reduces the amount of data that must then
> be compressed.
>
> OpenSSL does provide some transparent crypto support. See:
> http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html

I thought all SSL traffic was compressed, unless you turned that off.
It is just SSH that is always compressed?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Carlo Stonebanks 2010-08-13 14:52:27 Re: Very bad plan when using VIEW and IN (SELECT...*)
Previous Message Tom Lane 2010-08-13 14:47:30 Re: Feature Request: bzip2 support in pg_dump, pg_restore