Gentoo Archives: gentoo-user

From: Grant Taylor <gtaylor@×××××××××××××××××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins?
Date: Fri, 28 Aug 2020 21:12:53
Message-Id: d0638f87-2201-9099-377f-b8b526de3f09@gentoo.tnetconsulting.net
In Reply to: Re: [gentoo-user] tips on running a mail server in a cheap vps provider run but not-so-trusty admins? by "Poison BL."
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

Replies