On 4/2/18 12:46, Tom Lane wrote:
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> I agree the attack is less likely to be applicable in typical database
>> installations. I think we should move forward with considering protocol
>> compression proposals, but any final result should put a warning in the
>> documentation that using compression is potentially insecure.
>
> It seemed like the attack you described wasn't all that dependent on
> whether the data is compressed or not: if you can see the size of the
> server's reply to "select ... where account_number = x", you can pretty
> well tell the difference between 0 and 1 rows, with or without
> compression. So I'm still not very clear on what the threat model is.
Well these could also be update commands or procedure calls with a
constant response size. Also, it doesn't matter whether the select
returns anything. Maybe it's not querying the main accounts table. But
it already shows that the client thinks that the account number is a
real one.
There are probably even better examples. But the main point is that if
an attacker can control part of what you send alongside some secret
thing, compression is going to be a security concern for some.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services