On 8/28/20 3:33 PM, Michael Orlitzky wrote:
TLS only secures the channel; what comes out at the end is a plain-text message that can be read with minimal effort by the VPS provider, no skullduggery needed.
I agree that STARTTLS only protects the email while it's in flight between servers.
Though I do think that it's going to somewhat difficult for a VPS provider to read the contents of the message if it's stored on an encrypted disk.
I think that taking a snapshot of a running VPS / VM with the disk encryption keys in memory and accessing it qualifies as skullduggery. Plus, they will still need to content with the authentication requirements of the running snapshot, just like they would with the running VPS / VM.
So things like LUKS definitely raises the bar and makes a VPS provider work a fair bit harder to access what's on the encrypted disk.
(And the private key for each TLS session is generated on-the-fly by the VPS anyway, so they could snoop on the channel too if they wanted to.)
Harvesting keys (TLS and / or LUKS) out of memory definitely qualifies as skullduggery.
You can only protect against so much. You have to find what is acceptable risk.
Unless the sender and recipient have some pre-shared secret (like GPG assumes),
I *REALLY* thought that PGP (GPG) was based on public & private key pairs, much like S/MIME and TLS.
As such, Alice and Bob can encrypt messages to each other, even through an untrusted medium such as a questionable email server.
Yes, that still leaves the bootstraping issue of how do Alice and Bob get each other's public key. -- I defer to my recent comments about publishing keys in DNS and relying on DNSSEC.
you're going to fall into the same trap that DRM falls into. The technology provides a way for Alice and Bob to communicate securely in the presence of Eve, but only when Alice, Bob, and Eve are three distinct people. If the VPS is playing the part of both Bob and Eve, an off-the-shelf encryption model isn't going to work.
I see no need for either Alice nor Bob to be on the VPS. I would expect that they are their own independent (smart) devices accessing their respective email servers. Don't put any unencrypted sensitive data on the central server(s).
Decrypting the emails in any capacity on the central server means that the gig is up and anyone with access, OS level or more nefarious, can access things.
-- Grant. . . . unix || die
