Re: Moving forward with TDE - Mailing list pgsql-hackers
| From | Stephen Frost |
|---|---|
| Subject | Re: Moving forward with TDE |
| Date | |
| Msg-id | CAOuzzgrdbiTiW4YX74-GEajNcpud-k3d-Aa7VmCeuvCh6z59+Q@mail.gmail.com Whole thread Raw |
| In response to | Re: Moving forward with TDE (Bruce Momjian <bruce@momjian.us>) |
| Responses |
Re: Moving forward with TDE
(Bruce Momjian <bruce@momjian.us>)
Re: Moving forward with TDE (Chris Travers <chris.travers@gmail.com>) |
| List | pgsql-hackers |
Greetings,
On Mon, Mar 27, 2023 at 12:38 Bruce Momjian <bruce@momjian.us> wrote:
On Wed, Mar 8, 2023 at 04:25:04PM -0500, Stephen Frost wrote:
> Agreed, though the latest efforts include an option for *authenticated*
> encryption as well as unauthenticated. That makes it much more
> difficult to make undetected changes to the data that's protected by
> the authenticated encryption being used.
I thought some more about this. GCM-style authentication of encrypted
data has value because it assumes the two end points are secure but that
a malicious actor could modify data during transfer. In the Postgres
case, it seems the two end points and the transfer are all in the same
place. Therefore, it is unclear to me the value of using GCM-style
authentication because if the GCM-level can be modified, so can the end
points, and the encryption key exposed.
What are the two end points you are referring to and why don’t you feel there is an opportunity between them for a malicious actor to attack the system?
There are simpler cases to consider than an online attack on a single independent system where an attacker having access to modify the data in transit between PG and the storage would imply the attacker also having access to read keys out of PG’s memory.
As specific examples, consider:
An attack against the database system where the database server is shut down, or a backup, and the encryption key isn’t available on the system.
The backup system itself, not running as the PG user (an option supported by PG and at least pgbackrest) being compromised, thus allowing for injection of changes into a backup or into a restore.
The beginning of this discussion also very clearly had individuals voicing strong opinions that unauthenticated encryption methods were not acceptable as an end-state for PG due to the clear issue of there then being no protection against modification of data. The approach we are working towards provides both the unauthenticated option, which clearly has value to a large number of our collective user base considering the number of commercial implementations which have now arisen, and the authenticated solution which goes further and provides the level clearly expected of the PG community. This gets us a win-win situation.
> There's clearly user demand for it as there's a number of organizations
> who have forks which are providing it in one shape or another. This
> kind of splintering of the community is actually an actively bad thing
> for the project and is part of what killed Unix, by at least some pretty
> reputable accounts, in my view.
Yes, the number of commercial implementations of this is a concern. Of
course, it is also possible that those commercial implementations are
meeting checkbox requirements rather than technical ones, and the
community has been hostile to check box-only features.
I’ve grown weary of this argument as the other major piece of work it was routinely applied to was RLS and yet that has certainly been seen broadly as a beneficial feature with users clearly leveraging it and in more than some “checkbox” way.
Indeed, it’s similar also in that commercial implementations were done of RLS while there were arguments made about it being a checkbox feature which were used to discourage it from being implemented in core. Were it truly checkbox, I don’t feel we would have the regular and ongoing discussion about it on the lists that we do, nor see other tools built on top of PG which specifically leverage it. Perhaps there are truly checkbox features out there which we will never implement, but I’m (perhaps due to what my dad would call selective listening on my part, perhaps not) having trouble coming up with any presently. Features that exist in other systems that we don’t want? Certainly. We don’t characterize those as simply “checkbox” though. Perhaps that’s in part because we provide alternatives- but that’s not the case here. We have no comparable way to have this capability as part of the core system.
We, as a community, are clearly losing value by lack of this capability, if by no other measure than simply the numerous users of the commercial implementations feeling that they simply can’t use PG without this feature, for whatever their reasoning.
Thanks,
Stephen
pgsql-hackers by date: