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:
> /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
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 |