Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompression assumption, defaults to SSL_OP_NO_COMPRESSION |
Дата | |
Msg-id | 6829.1496457815@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL's sslcompressionassumption, defaults to SSL_OP_NO_COMPRESSION (greenreaper@hotmail.com) |
Ответы |
Re: [BUGS] BUG #14686: OpenSSL 1.1.0+ breaks PostgreSQL'ssslcompression assumption, defaults to SSL_OP_NO_COMPRESSION
|
Список | 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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: