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 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
