Re: Transparent Data Encryption (TDE) and encrypted files

On Fri, Oct 04, 2019 at 07:52:48AM +0200, Magnus Hagander wrote:
>On Fri, Oct 4, 2019 at 3:42 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
>>
>> > It doesn't seem like it would require
>> > much work at all to construct an argument that a hacker might enjoy
>> > having unfettered access to pg_clog even if no other part of the
>> > database can be read.
>>
>> The question isn't about what hackers would like to have access to, it's
>> about what would actually provide them with a channel to get information
>> that's sensitive, and at what rate. Perhaps there's an argument to be
>> made that clog would provide a high enough rate of information that
>> could be used to glean sensitive information, but that's certainly not
>> an argument that's been put forth, instead it's the knee-jerk reaction
>> of "oh goodness, if anything isn't encrypted then hackers will be able
>> to get access to everything" and that's just not a real argument.
>>
>
>Huh. That is *exactly* the argument I made. Though granted the example was
>on multixact primarily, because I think that is much more likely to leak
>interesting information, but the basis certainly applies to all the
>metadata.
>

IMHO we should treat everything as a serious side-channel by default,
and only consider not encrypting it after presenting arguments why
that's not the case. So we shouldn't be starting with unencrypted clog
and waiting for folks to come up with attacks leveraging that.

Of course, it's impossible to prove that something is not a serious
side-channel (it might be safe on it's own, but not necessarily when
combined with other side-channels). And it's not black-and-white, i.e.
the side-channel may be leaking so little information it's not worth
bothering with. And ultimately it's a trade-off between complexity of
implementation and severity of the side-channel.

But without at least trying to quantify the severity of the side-channel
we can't really have a discussion whether it's OK not to encrypt clog,
whether it can be omitted from v1 etc.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services