On 11/10/21 16:54, Andrey Borodin wrote:
>
>
>> Daniel Gustafsson <daniel@yesql.se> writes:
>>
>>> 2773: libpq compression
>>> =======================
>>> This patch intended to provide libpq connection compression to "replace SSL
>>> compression" which was doomed when the patch was written, and have since been
>>> removed altogether. The initial approach didn't get much traction but there
>>> was significant discussion and work, which has since fizzled out. The patch
>>> has been updated but there hasn't been meaningful review the past months, the
>>> last comments seem to imply there being a fair amount of questionmarks left in
>>> here. Robert, having been very involved in this do you have any thoughts on
>>> where we are and where to go (if at all IYO)?
>>
>> I'm not Robert, but I still have an opinion here, and that it's that this
>> feature would at best be an attractive nuisance. If you need compression
>> on a database session, it probably means that the connection is over the
>> open internet, which means that you need encryption even more. And we
>> know that compression and encryption do not play well together. The
>> reason compression was taken out of the latest TLS standards is not that
>> they wouldn't have liked to have it, nor that applying compression in a
>> separate code layer would be any safer. I fear offering this would
>> merely lead people to build CVE-worthy setups.
>>
>
> Compression is crucial for highly available setups. Replication traffic is often billed. Or route has bandwidth
limits.
> An entropy added by WAL headers makes CRIME attack against replication encryption impractical.
I very much doubt WAL headers are a reliable protection against CRIME,
because the entropy of the headers is likely fairly constant. So if you
compress the WAL stream, the WAL headers may change but the compression
ratio should be pretty similar. At least that's my guess.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
