Greetings,
* Andrey Borodin (x4mmm@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
serveron 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