Re: libpq compression

> 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 https://vmware.com/