On 11/10/21 16:54, Andrey Borodin wrote:
Daniel Gustafsson <dan...@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
