On Mon, May 20, 2024 at 2:05 PM Andrey M. Borodin <x4...@yandex-team.ru> wrote: > Compression defeats encryption. That's why it's not in TLS anymore. > The thing is compression codecs use data self correlation. And if you mix > secret data with user's data, user might guess how correlated they are.
Yeah, I'm aware that there are some problems like this. For example, suppose the bad guy can both supply some of the data sent over the connection (e.g. by typing search queries into a web page) and also observe the traffic between the web application and the database. Then they could supply data and try to guess how correlated that is with other data sent over the same connection. But if that's a practical attack, preventing compression prior to the authentication exchange probably isn't good enough: the user could also try to guess what queries are being sent on behalf of other users through the same pooled connection, or they could try to use the bits of the query that they can control to guess what the other bits of the query that they can't see look like. But, does this mean that we should just refuse to offer compression as a feature? This kind of attack isn't a threat in every environment, and in some environments, compression could be pretty useful. For instance, you might need to pull down a lot of data from the database over a slow connection. Perhaps you're the only user of the database, and you wrote all of the queries yourself in a locked vault, accepting no untrusted inputs. In that case, these kinds of attacks aren't possible, or at least I don't see how, but you might want both compression and encryption. I guess I don't understand why TLS removed support for encryption entirely instead of disclaiming its use in some appropriate way. -- Robert Haas EDB: http://www.enterprisedb.com