Re: BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: greenreaper(at)hotmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION
Date: 2017-06-03 02:43:35
Message-ID: 6829.1496457815@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

greenreaper(at)hotmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hans Buschmann 2017-06-03 15:48:27 Re: BUG #14684: pg_dump omits columns in inherited tables / psql -d shows deleted columns
Previous Message Shawn Doyle 2017-06-03 02:40:13 Re: HP-UX 11.31 Itanium2 64bit again