On Tue, Nov 9, 2021 at 12:43:20PM -0500, Stephen Frost wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Daniel Gustafsson <daniel@yesql.se> writes:
> > 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.
>
> I've got an opinion on this also and I don't agree that needing
> compression means you're on the open internet or that we shouldn't allow
> users the choice to decide if they want to use compression and
> encryption together or not. Yes, there's potential risks there, but I
> don't think those risks would lead to CVEs against PG for supporting a
> mode where we allow compression and then also allow encryption- if
> that's a problem then it's an issue for the encryption library/method
> being used and isn't the fault of us for allowing that combination.
Yeah, I am leaning this diretion too. On the one hand, the number of
ways to exploit compression-then-encryption seem to continue to grow,
but it is the complex behavior of HTTPS and connecting to multiple sites
which seems to always be required, and we don't do that with the
Postgres client/server protocol.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.