On Sat, May 30, 2015 at 4:58 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Apr 16, 2015 at 4:26 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Apr 15, 2015 at 9:42 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Wed, Apr 15, 2015 at 9:20 PM, Michael Paquier
>>> <michael.paquier@gmail.com> wrote:
>>>> On Wed, Apr 15, 2015 at 2:22 PM, Fujii Masao wrote:
>>>>> On Wed, Apr 15, 2015 at 11:55 AM, Michael Paquier wrote:
>>>>>> 1) Doc patch to mention that it is possible that compression can give
>>>>>> hints to attackers when working on sensible fields that have a
>>>>>> non-fixed size.
>>>>>
>>>>> I think that this patch is enough as the first step.
>>>>
>>>> I'll get something done for that at least, a big warning below the
>>>> description of wal_compression would do it.
>>
>> So here is a patch for this purpose, with the following text being used:
>> + <warning>
>> + <para>
>> + When enabling <varname>wal_compression</varname>, there is a risk
>> + to leak data similarly to the BREACH and CRIME attacks on SSL where
>> + the compression ratio of a full page image gives a hint of what is
>> + the existing data of this page. Tables that contain sensitive
>> + information like <structname>pg_authid</structname> with password
>> + data could be potential targets to such attacks. Note that as a
>> + prerequisite a user needs to be able to insert data on the same page
>> + as the data targeted and need to be able to detect checkpoint
>> + presence to find out if a compressed full page write is included in
>> + WAL to calculate the compression ratio of a page using WAL positions
>> + before and after inserting data on the page with data targeted.
>> + </para>
>> + </warning>
>>
>> Comments and reformulations are welcome.
>
> To make things on this thread move on, I just wanted to add that we
> should make wal_compression SUSET
I'm OK to make it SUSET.
Regards,
--
Fujii Masao