Re: Commitfest 2021-11 Patch Triage - Part 2

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Commitfest 2021-11 Patch Triage - Part 2
Date: 2021-11-14 19:13:12
Message-ID: 20211114191312.GC26257@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Andrey Borodin (x4mmm(at)yandex-team(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-14 19:26:33 Re: Commitfest 2021-11 Patch Triage - Part 2
Previous Message Tom Lane 2021-11-14 19:11:30 Re: Inconsistent error message for varchar(n)