1 |
On 8/28/20 1:54 PM, Poison BL. wrote: |
2 |
> I'm rather late to the game with this, but at the end of the day, |
3 |
> mail coming *into* a mail server isn't typically encrypted (and even |
4 |
> that is only the body, the headers can still reveal a great deal, |
5 |
> and are necessary for the server to work with it). |
6 |
|
7 |
You seem to be referring to S/MIME and / or PGP encryption. You are |
8 |
correct that S/MIME and PGP don't offer protection for headers. |
9 |
|
10 |
However, STARTTLS provides an encrypted channel to protect all of the |
11 |
SMTP traffic. Thus, even the headers of email are encrypted while in |
12 |
flight between servers. |
13 |
|
14 |
> A packet dump at the switch will turn over every piece of mail you |
15 |
> receive along the way. |
16 |
|
17 |
When STARTTLS is in use, the only thing that you will see is the initial |
18 |
EHLO and STARTTLS commands. Everything after that will be encrypted |
19 |
traffic. |
20 |
|
21 |
> Email's not designed for end to end security by default. |
22 |
|
23 |
Encryption for anything other than military use didn't really exist when |
24 |
email was developed. |
25 |
|
26 |
Since then, things like STARTTLS (or SMTPS if you choose to abuse it for |
27 |
B2B connections) and VPNs have become a realistic option. |
28 |
|
29 |
Most contemporary MTAs will opportunistically use STARTTLS if it is an |
30 |
option. We only need to worry about things that try to prevent STARTTLS |
31 |
from working. Thankfully, this is mostly authoritarian regimes in some |
32 |
parts of the world. |
33 |
|
34 |
> Secondly, any hosting on hardware you don't control is impossible |
35 |
> to fully secure, if the services on that end have to operate on |
36 |
> the data at all. You can encrypt the drive, encrypt the mail stores |
37 |
> themselves, etc, but all of those things will result in the encryption |
38 |
> key being loaded into ram while the VPS is running, and dumping ram |
39 |
> from the hypervisor layer destroys every illusion of security you |
40 |
> had. |
41 |
|
42 |
I agree those are all valid concerns. However, we shouldn't let the |
43 |
inability to realistically have perfect prevent us from having something |
44 |
better than no encryption. |
45 |
|
46 |
> Dedicated hardware in a locked cabinet is as close as you get to |
47 |
> preventing physical attacks when you're hosting in someone else's DC, |
48 |
> and that's not nearly in the same market segment, price-wise, as a |
49 |
> cheap VPS. At best, if you have sensitive email that you're sending |
50 |
> or receiving, work with the other end of the communication and then |
51 |
> encrypt the contents properly. Even better, go with a larger scale, |
52 |
> paid, solution in which your email isn't even remotely worth the |
53 |
> effort to tamper with for the hosting company's employees, and hope |
54 |
> the contractual obligations are sufficient to protect you. |
55 |
|
56 |
I'm not aware of any place that contracts will protect you against local |
57 |
court orders / government involvement. |
58 |
|
59 |
> If you have any sort of controlled data going in and out of your email, |
60 |
> step up to a plan that adheres to the regulatory frameworks you're |
61 |
> required to adhere to and make very sure the contracts for it obligate |
62 |
> the vendor to secure things properly on their end (aws, azure/o365/etc |
63 |
> mostly all have offerings for, at least, US Gov level requirements). |
64 |
|
65 |
Yep. |
66 |
|
67 |
|
68 |
|
69 |
-- |
70 |
Grant. . . . |
71 |
unix || die |