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: Wed, 26 Aug 2020 18:52:00
Message-Id: 8038ed2e-585e-42dc-f0d2-a9d3eb83bd13@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 Rich Freeman
1 On 8/21/20 5:58 PM, Rich Freeman wrote:
2 > It is what just about every other modern application in existence uses.
3
4 VoIP does not.
5
6 No RDBMSs that I'm aware of use it as their primary protocol. (Some may
7 be able to use HTTP(S) as an alternative.)
8
9 Outlook to Exchange does (did?) not use it. It does have a sub-optimal
10 RPC-over-HTTP(S) option for things like mobile clients. But you still
11 get much better service using native non-HTTP(S) protocols.
12
13 I'm not aware of any self hosted enterprise grade remote desktop
14 solution that uses HTTP(S) as it's native transport.
15
16 Just because it's possible to force something to use HTTP(S) does not
17 mean that it's a good idea to do so.
18
19 > I'm sure there are hundreds of articles on the reasons for this that
20 > are far better than anything I'd come up with here.
21
22 Probably.
23
24 > And they don't work for anything OTHER than SMTP.
25
26 There are /other/ libraries that work for /other/ things.
27
28 Having a general thing that can be abused for almost all things is
29 seldom, if ever, the optimal way to achieve the goal.
30
31 > A library for JSON/webservices/whatever works for half the applications
32 > being written today.
33
34 I choose to believe that even that 50% is significantly sub-optimal and
35 that they have been pressed into that role for questionable reasons.
36
37 > This is simple. This is how just about EVERYBODY does it these days.
38
39 I disagree.
40
41 Yes, a lot of people do. But I think it's still a far cry from "just
42 about everybody".
43
44 > http works as a transport mechanism.
45
46 Simply working is not always enough. Dial up modems "worked" in that
47 data was transferred between two endpoints. Yet we aren't using them today.
48
49 Frequently, we want optimal or at least the best solution that we can get.
50
51 > That is the beauty of standards like this - somebody else figured out
52 > SSL on top of HTTP so we don't need an email-specific reimplementation
53 > of that.
54
55 I think that you are closer than you realize or may be comfortable with.
56
57 "somebody else figured out" meaning that "someone else has already done
58 the work or the hard part". Meaning that it's possible to ride people's
59 coat tails.
60
61 HTTP(S) as a protocol has some very specific semantics that make it far
62 from ideal for many things. Things like the server initiating traffic
63 to clients. Some, if not many, of these semantics impose artificial
64 limitations on services.
65
66 > I mean, why use TCP?
67
68 For starters, TCP ensures that your data arrives at the other end (or
69 notifies you if it doesn't), that it's in order, and that it's not
70 duplicated.
71
72 There are multiple other protocols that you can use. UDP is a prominent
73 one.
74
75 > Why not use something more tailored to email?
76
77 Now you're comparing an application layer protocol (email(SMTP)) to a
78 network transport protocol (TCP / UDP / etc.).
79
80 What transport layer protocol would you suggest using?
81
82 Be careful to trace higher layer abstraction protocols, e.g. QUIC, back
83 down to the transport layer protocol (UDP in QUIC's case).
84
85 > TCP probably has a dozen optional features that nobody uses with email,
86 > so why implement all that just to send email?
87
88 What contemporary operating system does not have a TCP/IP stack already?
89
90 How are applications on said operating system speaking traditional /
91 non-QUIC based HTTP(S) /without/ TCP?
92
93 Even exclusively relying on QUIC still uses UDP.
94
95 > The answer is that it makes WAY more sense to recycle a standard
96 > protocol than to invent one.
97
98 You're still inventing a protocol. It's just at a higher layer. You
99 still have to have some way / method / rules / dialect, more commonly
100 known as a protocol, on whatever communications transport you use.
101
102 Even your web based application needs to know how to communicate
103 different things about what it's doing. Is it specifying the sender or
104 the recipient or the subject or something else. Protocols are what
105 define that. They are going to exist. It's just a question of where
106 they exist.
107
108 You're still inventing a protocol.
109
110 Do you want your protocol to run on top of a taller more complex stack
111 of dependencies? Or would you prefer a shorter simpler stack of
112 dependencies?
113
114 You're still inventing a protocol. You're just choosing where to put
115 it. And you seem to be in favor of the taller more complex stack.
116 Conversely I am in favor of the shorter simpler stack.
117
118 > If SMTP didn't exist, and we needed a way to post a bunch of data to
119 > a remote server, you'd use HTTP, because it already works.
120
121 No. /I/ would not.
122
123 HTTP(S) is inherently good at /retrieving/ data. We have used and
124 abused HTTP(S) to make it push data.
125
126 Depending what the data was and the interactive nature of it, I would
127 consider a bulk file transfer protocol FTPS / SFTP / SCP or even NAS
128 protocols. Things that are well understood and well tested.
129
130 If I had some reason that they couldn't do what I needed or as
131 efficiently as I needed, I would develop my own protocol. I would
132 certainly do it on top of a transport protocol that ensured my data
133 arrived (or it told me), in order, and not duplicated.
134
135 I could develop my own protocol that allowed me to start from a clean
136 slate and did not impose rules on what I could say or how I would say
137 it. HTTP(S) starts with impositions of what you can say and how you can
138 say it.
139
140 If you are creating something completely green field that rides entirely
141 on top of HTTP(S), you have issues with bidirectionality and / or
142 latency and / or request reply correlation by how the HTTP protocol
143 operates.
144
145 TCP is so easy to use that simple Bash shell scripts can utilize it by
146 opening files.
147
148 TCP already works too. And TCP works without the additional overhead of
149 HTTP stack on top of it.
150
151 > It isn't just the trust problem. It is also the ease of use problem.
152
153 I believe that the trust part of the problem is significantly more
154 difficult than the ease of use part of the problem.
155
156 > Let's assume you trust all the CAs out there. Why isn't anybody using
157 > SSL for email?
158
159 My personal opinion is that laziness and / or ignorance are the two
160 biggest impediments.
161
162 > It is built into half the email clients out there.
163
164 I suspect that it's significantly more than half. I would speculate
165 that it's more like > 90% of the mainstream email clients support
166 encrypted communications channels; STARTTLS / SMTPS / IMAPS / POP3S / LDAPS.
167
168 I speculate that all contemporary desktop email clients support at leat
169 one form of encrypted message; S/MIME and / or PGP.
170
171 Mobile clients may be more problematic. I know that Apple's Mail.app on
172 iOS has supported S/MIME for as long as I've been using it, 10+ years.
173 I don't know about the Android ecosystem. I would be shocked if there
174 wasn't an email client that supported S/MIME. PGP may be more spotty.
175
176 > The problem is that exchanging certificates at an individual level
177 > is hard.
178
179 No it is not. Not with a decent S/MIME implementation.
180
181 I send someone a /signed/ message, and their reputable MUA learns my
182 public key from my signature. (With requisite PKI/CA signing my keys.)
183
184 Then when that person sends me a message, their reputable MUA will
185 automatically encrypt messages to me using my public key.
186
187 I can even learn their public key from the signature that they apply to
188 the message that they encrypt to me.
189
190 This is, or can be, almost completely transparent to end users. The
191 only non-transparent part of of actual day-to-day use of S/MIME is the
192 occasional "Would you like to use $SENDER's public key when
193 communicating with them in the future?" type pop-up. Thunderbird with
194 one add-on streamlines even that.
195
196 Even installing the certificate is not any more difficult than original
197 email account configuration. Admittedly it needs to happen again at
198 certificate renewal time. So there is some room for improvement here.
199 But even this is not a high bar. I don't believe this is a barrier to
200 adoption.
201
202 The most difficult (read: annoying) part of S/MIME is acquiring the
203 S/MIME certificate. Even that's not unduly difficult.
204
205 > Oh, for an organization with an IT department it isn't a problem.
206 > The IT department can just issue a certificate to everybody,
207 > generating keys for them. Then it can stick all the certs in some
208 > kind of directory that their email clients all use.
209
210 Doing anything with S/MIME (or PGP) at scale like you would as an
211 individual is obviously untenable. But there are other options that
212 help with businesses. It's possible to acquire a certificate that will
213 allow you to sign other certificates. (It don't think it's a
214 code-signing-certificate, but rather something quite similar.)
215
216 > Getting your cousin to use SSL certs for their email is a whole
217 > different matter.
218
219 This is where the aforementioned "ignorance" comes in. I don't mean
220 anything against your cousin, or anybody else for that matter. But the
221 simple lack of simple understanding of what it is, why it's important,
222 or how to do it is, in my humble opinion, the BIGGEST impediment to this.
223
224 I mean "ignorance" in the way that most 3-5 year old kids are ignorant
225 about how to read. They simply have not been exposed to or learned how
226 to do it yet. There is no malicious intent.
227
228 > Heck, just using it between two different companies, both supported by
229 > professional IT depts, is a pain.
230
231 I see no reason for it to be a pain. Can someone acquire the
232 certificate(s) on the employees behalf? Can someone install them in the
233 employees email client?
234
235 Thunderbird with one simple add-on will automatically sign messages by
236 default.
237
238 As previously stated, sending a signed message contains sufficient
239 information to boot strap S/MIME.
240
241 The same add-on will automatically encrypt message to recipients that
242 Thunderbird has seen a (current) public key from.
243
244 So the end user simply needs to open Thunderbird and send an email.
245 Which I'm fairly sure that there are hundreds of thousands of people
246 doing already.
247
248 So, I'm back to ignorance and laziness. Some of the ignorance is out of
249 laziness and may be hedging on malicious complacency.
250
251 Businesses /can/ make encryption trivial to use. Debian made it trivial
252 to do so when I signed up for something. The portal that I used had an
253 option to upload my public key. Uploading my public key is all that was
254 required to receive S/MIME (or PGP) encrypted email from them.
255
256 It is possible to make end-to-end encrypted email much less of an
257 affront than it is or worse, what many people seemingly believe that it is.
258
259 So, again, back to ignorance and / or laziness.
260
261 > You could use TLS for the transport itself...
262
263 Yes.
264
265 This is and has been best practice for a decade or more.
266
267 > ... have the email servers configured to only use TLS for those domains,
268
269 This is currently a manual process.
270
271 I would like to see some more automation around this.
272
273 I believe there is some work effort with DNS-based Authentication of
274 Named Entities (DANE) -and- MTA support to dynamically learn about and
275 enforce TLS requirement.
276
277 > but actually doing E2E encryption is hard with email because there
278 > aren't a lot of standards for key exchange across unrelated orgs.
279
280 S/MIME is self bootstraping. Signed emails, which can be sent to
281 anyone, provide the sender's public key. There is no need for any
282 external involvement. MUAs can completely handle this.
283
284 > DNSSEC is:
285 >
286 > 1. Still poorly supported even where it makes sense.
287
288 Yet another example of ignorance and / or laziness.
289
290 I have found DNSSEC to be relatively easy to implement, and trivial to
291 enable on my recursive resolvers.
292
293 The ignorance portion is relatively easy to resolve if people want to.
294 I highly recommend DNSSEC Mastery by Michael W. Lucas. That $20 (?)
295 book and moderate amounts of motivation is all anybody that wants to
296 implement DNSSEC /needs/.
297
298 > 2. A great hypothetical solution for the 0.002% of email users who
299 > own a domain name, like you and me.
300
301 DNSSEC can be used for FAR more than just email domains.
302
303
304
305 --
306 Grant. . . .
307 unix || die

Replies