Bruce Momjian wrote:
SSL is NOT always compressed at the data level. SSH is if you ask for it, but by default SSL is NOT.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.htmlI thought all SSL traffic was compressed, unless you turned that off. It is just SSH that is always compressed? This is a common (and false) belief. -- Karl |
begin:vcard fn:Karl Denninger n:Denninger;Karl email;internet:karl@xxxxxxxxxxxxx x-mozilla-html:TRUE version:2.1 end:vcard
-- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general