Bruce Momjian wrote:
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?
SSL is NOT always compressed at the data level. SSH is if you ask for it, but by default SSL is NOT.
This is a common (and false) belief.
-- Karl