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