From: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Compression on SSL links? |
Date: | 2010-08-13 15:04:40 |
Message-ID: | 4C655F08.2020301@postnewspapers.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 13/08/2010 10:43 PM, Craig Ringer wrote:
> OpenSSL does provide some transparent crypto support. See:
> http://www.openssl.org/docs/ssl/SSL_COMP_add_compression_method.html
Some more info on this:
Apache mod_ssl docs mention that SSLv3 handshake is required to
negotiate compression in SSL. That shouldn't be a big issue for
postgresql, and at worst would just require a flag to switch back to
SSLv2 for incredibly ancient servers (if there are even any out there).
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#comp
It also shows that OpenSSL's docs are out of date, because there's a
standard way to negotiate DEFLATE compression (zlib/gzip). Not that Pg
would need that, but it's nice to have a standard name to use and it
might help with non-OpenSSL implementations like JSSE/JCA for Java/JDBC.
See: http://www.ietf.org/rfc/rfc3749.txt
Unfortunately there's no reference to DEFLATE or to compression in the
JSSE standard docs, and the latest information I can find (admittedly
from 2007) says "Compression is not supported by Sun's JSSE provider. ".
Sigh. No compression for PgJDBC SSL. There's a 3rd pty JSSE provider
called "Jessie" that claims to support SSL compression, but it looks
pretty dead and I don't see people wanting compression that badly anyway.
So: It looks like SSL/TLS level compression is supported by OpenSSL, but
I don't see much indication that it's widely adopted. I can't find any
evidence Microsoft support it in their SSL/TLS implementation either.
Win2k3's explicitly lacks it, so even if it's been added since it won't
be widely deployed.
Overall: it sounds to me like SSL/TLS level compression would only be
useful for native libpq-to-postgresql connections, and probably wouldn't
be usable for non-libpq based database access drivers. It'd only work if
SSL was configured, which is a limitation it'd be nice to avoid. Plus,
it doesn't look like it's a clear-cut obviously backward compatible
change - there's the need to use the SSLv3 handshake, issues with late
standardization of compression protocol names, the fact that
distributions of OpenSSL might not be built with compression support, etc.
Personally, after looking into it a little, I'm not even close to
interested enough to do the required patching and compatibility testing.
Adding compression to the postgresql protocol would be much harder, but
looks like it'd be much more worthwhile. It's not something I personally
care about or want to look into though.
--
Craig Ringer
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Hunsberger | 2010-08-13 15:11:22 | Re: ORM integration? |
Previous Message | Tom Lane | 2010-08-13 15:03:37 | Re: Very bad plan when using VIEW and IN (SELECT...*) |