> On 22 Feb 2021, at 22:21, Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2021-02-22 15:44:30 -0500, Tom Lane wrote: >> Robert Haas <robertmh...@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'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/
