Re: BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: greenreaper@hotmail.com
Cc: pgsql-bugs@postgresql.org
Date: 2017-06-03T02:43:35Z
Lists: pgsql-bugs
greenreaper@hotmail.com writes: > PostgreSQL is documented to compress data over SSL connections by default > where possible: > https://www.postgresql.org/docs/9.6/static/libpq-connect.html#LIBPQ-CONNECT-SSLCOMPRESSION > PostgreSQL assumes that OpenSSL 0.9.8+ will compress with zlib if it can. > However, OpenSSL 1.1.0+ - already in Manjaro, and the upcoming Debian 9 > 'Stretch', Fedora 26, and Tails 3.0 - sets SSL_OP_NO_COMPRESSION by default > to discourage the CRIME attack: So the actual issue here, which you've not addressed in this otherwise extensive screed, is whether it's a wise thing for us to override that decision. Should we not just change sslcompression into a no-op? Is there some reason why PG data is immune to the CRIME attack? We might in the future consider compressing the data for ourselves inside the SSL stream, but (a) that would be a protocol break, with a pile of unpleasant compatibility consequences, and (b) if compression by OpenSSL itself makes the stream more decryptable, wouldn't app-provided compression inside the stream also do that? In short I'm wondering whether app-driven transport data compression is an idea whose time has passed. regards, tom lane