Search Postgresql Archives

Re: Compression on SSL links?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux