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. +
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 |