Received-SPF: SoftFail (connect.ultra-secure.de: domain of ultra-secure.de does not designate 127.0.0.10 as permitted sender) receiver=connect.ultra-secure.de; identity=mailfrom; client-ip=127.0.0.10; helo=connect.ultra-secure.de; envelope-from=<rainer@ultra-secure.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 17 Oct 2025 16:08:14 +0200
From: rainer@ultra-secure.de
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>, pgsql-general
 <pgsql-general@postgresql.org>
Subject: Re: Enquiry about TDE with PgSQL
In-Reply-To: <CAKAnmmKjyG3jOhFRP_wq_Hm0Zi6t8esx8Xsxqkjn9BPkAXmeMw@mail.gmail.com>
References: <CACgMzfwSDRF+kQr59h0-xGUobCeFZxwVzE_tUxF18DkVb+vuDQ@mail.gmail.com>
 <CAKAnmmKDCOdUT5JtJZz5papMO0zW1cnG4934d6aQVCQ_KdbUeg@mail.gmail.com>
 <CANzqJaA41CzNjkiQex+A0u9z11i6R3WQZJ+fkXfJO7VJwOMWzg@mail.gmail.com>
 <CAKAnmmKjyG3jOhFRP_wq_Hm0Zi6t8esx8Xsxqkjn9BPkAXmeMw@mail.gmail.com>
Message-ID: <2945566374f0a3698e3794ac16632dd8@ultra-secure.de>
User-Agent: Roundcube Webmail/1.2.0
Archived-At: <https://www.postgresql.org/message-id/2945566374f0a3698e3794ac16632dd8%40ultra-secure.de>
Precedence: bulk

Am 2025-10-17 15:12, schrieb Greg Sabino Mullane:
> On Fri, Oct 17, 2025 at 12:49 AM Ron Johnson
> <ronljohnsonjr@gmail.com> wrote:
> 
>> But filesystem encryption still means that validly logged-in users
>> see the unencrypted data.  That's great for a laptop that might get
>> stolen, or for drives that are discarded without being wiped, but
>> are no protection against hackers who want to exfiltrate your data.
> 
> I stand by my recommendation. If someone is logged in and has access
> to your data directory (e.g. is root or postgres user), then they also
> have the TDE key or some easy way to bypass it.
> 
>> TDE was added to SQL Server, with (to us, at least)
>> minimally-noticed overhead.  Oracle has it, too, but I don't know
>> the details.
>> The bottom line is that requirements for TDE are escalating, whether
>> you like it or not
> 
> I'm not arguing against putting TDE in Postgres - indeed, I am all for
> that. But it's a very tricky thing to do technically, with minimal
> benefits other than "checking the box" of some security requirements
> document.
> 
>> The bottom line is that requirements for TDE are escalating, whether
>> you like it or not, as Yet Another Layer Of Defense against hackers
>> exfiltrating data, and then threatening to leak it to the public.
> 
> I'd love to see a real-world example where TDE would have saved
> someone but disk encryption could not.


At least with Oracle and TDE, the rman backups are encrypted, too.
So, you cannot just download the dumps from a file-share and import them 
somewhere else (or if you get hold of the tapes, use those to restore 
the files).
It's not really about protecting the files from a hacker but from a 
person inside the organization who wants to sell the data.

TDE really only (IMHO) makes sense when you also have a HSM.


Now, I've seen a case where a customer had Oracle + Dataguard + TDE + 
HSM.

The thing is, you rarely interact with the HSM normally. So, it's 
getting a bit hazy in that department when you have to add a new 
secret...plus, while Oracle and the HSM vendor will happily license you 
the feature, they will happily point their fingers at each other in case 
a problem arrives.

In this case, the HSM was wiped clear of all the keys in there, in an 
attempt to add a new key.
Oracle closed the wallets and the database was offline.

Dang!

Now, you had fix figures worth of hardware doing exactly nothing.

Due to incredibly lucky circumstances, it was possible to recover the 
database without data loss.

So, with TDE, you really need to be sure you actually know what you're 
doing.