Re: libpq compression

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Daniil Zakhlystov <usernamedt(at)yandex-team(dot)ru>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: libpq compression
Date: 2021-02-22 21:29:12
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 22 Feb 2021, at 22:21, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Hi,
> On 2021-02-22 15:44:30 -0500, Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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'm not a cryptographer either in any shape or form, but the above matches my
understanding of the CRIME and BREACH style of attacks in relation to postgres.

Daniel Gustafsson

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-02-22 22:28:47 locking [user] catalog tables vs 2pc vs logical rep
Previous Message Andres Freund 2021-02-22 21:21:58 Re: libpq compression