Date: Mon, 22 Feb 2021 13:21:58 -0800
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>,
	Daniil Zakhlystov <usernamedt@yandex-team.ru>,
	Konstantin Knizhnik <knizhnik@garret.ru>,
	Justin Pryzby <pryzby@telsasoft.com>,
	Andrey Borodin <x4mmm@yandex-team.ru>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: libpq compression
Message-ID: <20210222212158.42e2wazztunkie3n@alap3.anarazel.de>
References: <6811D196-E2FB-40CC-B1C9-F19427FBF675@yandex-team.ru>
 <CA+TgmoZMTLydjP3iWBir20OrSXTugxS2CXC1WP1nWM5=Zqz0Nw@mail.gmail.com>
 <A1D0D9A4-1FC4-4311-83C7-EEA90749EE07@yandex-team.ru>
 <CA+TgmoZrM9T_W9YR-vLYZXj-vC_+F-DER65A87+pDXRwUFjJXg@mail.gmail.com>
 <D5354E7A-3B9F-4D32-B3AB-F65058D36500@yandex-team.ru>
 <CA+TgmobPjqe-89PRH_qGHMWruXPK-Ya9tABEFuCvv1j26m5Efw@mail.gmail.com>
 <470E411E-681D-46A2-A1E9-6DE11B5F59F3@yandex-team.ru>
 <3676BA4F-ED2B-470C-9892-007C943BB1D2@yandex-team.ru>
 <CA+TgmobucpYrZoQL8=qcuoeodpmZu2w2=AiJiPNypL9=Hq07gw@mail.gmail.com>
 <3604970.1614026670@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3604970.1614026670@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2021-02-22 15:44:30 -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > So at the end of the day I'm not really quite sure what is best here.
> > I agree with all of Craig's points about the advantages of
> > packet-level compression, so I'd really prefer to make that approach
> > work if we can. However, it also seems to me that there's room to be
> > fairly concerned about what these test results are showing.
> 
> BTW ... in view of the nearby thread about permanently disabling
> OpenSSL's compression option, I wonder whether we really ought to be
> in a hurry to put back compression underneath that.  While this area
> is out of my wheelhouse, my understanding of the problem with OpenSSL
> is that the packet length changes due to compression can provide
> enough information to an attacker to break the encryption.  It seems
> to me that do-it-ourselves compression would most likely create an
> equivalent vulnerability.

My understanding is that one can infer compressed content only when an
attacker can control a part of the *same* encrypted & compressed message
that the desired-to-be-inferred data is in.  That is possible for
browsers, because in many cases e.g. a cookie containing a session
identifier will be sent to a server even when the request is issued from
some other website (e.g. by injecting lots "images" on a page, to get
around the same origin policy). That other website doesn't normally have
access to the cookies. But with compression it can make guesses at the
cookie value (think adding "Cookie: a" somewhere in the request, then
trying "Cookie: b", ...) and if the length is shorter than in other
cases the guess was right.

There's not really something equivalent in the postgres case. The
attacker needs to be able to influence the content in a lot of repeated
encrypted packets between client/server that are otherwise unchanged (or
predictable). It's possible that you can come up with something
contorted if the attacker controls the data the client requests, but
I don't think it's a comparable risk.

Not a cryptographer by any means though.


I think the majority of the cases where one would want to use libpq
compression are pretty much unaffected by such attacks, even on a
theoretical level. And for the remainder I suspect that we'd already
be vulnerable, due to to wal_compression.

Greetings,

Andres Freund