Greetings, * Andrey Borodin (x4...@yandex-team.ru) wrote: > > On 11/10/21 16:54, Andrey Borodin wrote: > >> Compression is crucial for highly available setups. Replication traffic is > >> often billed. Or route has bandwidth limits. > >> An entropy added by WAL headers makes CRIME attack against replication > >> encryption impractical. > > > > I very much doubt WAL headers are a reliable protection against CRIME, > > because the entropy of the headers is likely fairly constant. So if you > > compress the WAL stream, the WAL headers may change but the compression > > ratio should be pretty similar. At least that's my guess. > > I've thought more about it and I agree. > To reliably protect against CRIME entropy of WAL headers must be comparable > with the entropy of possibly injected data. > If this would stand, probably, our WAL would need a really serious rework. > > Maybe just refuse to enable compression on SSL connection? If someone really > needs both - they will just patch a server on their own. > Or make a GUC "yes_i_kwow_what_crime_is_give_grant_read_on_my_data_to_spies".
Attackers aren't likely to have the kind of isolated control over the data in the WAL stream (which is a combination of data from lots of ongoing activity in the system and isn't likely to be exactly what the attacker supplied at some higher level anyway) and the ability to read and analyze the WAL stream from a primary to a replica to be able to effectively attack it. None of this kind of babysitting makes any sense to me. I'm certainly fine with documenting that there are cases where compression of data sent by an attacker and then sent over an encrypted channel has been able to break the encryption and let admins decide if it's appropriate or not for them to use in their environment. Thanks, Stephen
signature.asc
Description: PGP signature
