
The sad state of SMTP encryption - FiloSottile
https://blog.filippo.io/the-sad-state-of-smtp-encryption/
======
Tepix
The article clarifies the issues that exist with SMTP encryption nicely.

Regarding the issue with certificates for the servers that the MX points to, I
disagree with the author. If the MX for example.com points to
mail.example.info, it implies that example.com trusting the handling of its
mail to mail.example.info, therefore there is no issue with letting
mail.example.info present its own certificate.

The article also suggests that DNSSEC with DANE will solve all issues with
SMTP encryption.

However, DNSSEC is a crappy standard. It doesn't do encryption so a
surveillant can still collect metadata; it has unsolved issues that facilitate
amplification attacks, it's overly complex and has slow adoption. In fact,
before DANE arrived on the scene, there was hardly a good reason to deploy it.

If we adopt DNSSEC now we'll be stuck with it (including its lack of privacy)
pretty much forever. Instead, I suggest we work on more promising initiatives
such as DNSCurve
([https://en.wikipedia.org/wiki/DNSCurve](https://en.wikipedia.org/wiki/DNSCurve))

~~~
talideon
> However, DNSSEC is a crappy standard. It doesn't do encryption so a
> surveillant can still collect metadata;

To be fair, on-the-wire encryption is a problem orthogonal to that which
DNSSEC is attempting to solve, which is integrity.

> it has unsolved issues that facilitate amplification attacks, it's overly
> complex and has slow adoption. In fact, before DANE arrived on the scene,
> there was hardly a good reason to deploy it.

Yup, DANE is essentially its killer app.

Any chance you could outline how you think it could be improved?

> If we adopt DNSSEC now we'll be stuck with it (including its lack of
> privacy) pretty much forever. Instead, I suggest we work on more promising
> initiatives such as DNSCurve
> ([https://en.wikipedia.org/wiki/DNSCurve](https://en.wikipedia.org/wiki/DNSCurve))

I don't think the case. As I wrote, DNSSEC aims to solve the issue of
integrity, not privacy. DNSCurve, or something like it, _should_ be deployed
alongside DNSSEC, with the former giving you privacy, and the latter ensuring
the integrity of the records. That way, even if the authoritative DNS server
itself is compromised, you can know whether the data you're getting from it
are OK or not. After all, it doesn't matter how good the pipe is if you're
getting sludge rather than the clean water you expect through it.

The big problem is that people, whether they're DNSSEC or DNSCurve advocates,
incorrectly put DNSSEC and DNSCurve in competition with each other, but this
isn't even remotely the case. We ought to be using _both_.

~~~
Tepix
DNSCurve also provides integrity. It cryptographically authenticates all DNS
responses.

With DNSSEC yes, you can store signed data on a server without having to store
the key on the same machine. It does make it even more complicated, however.
With HTTPS, IMAPS, SMTPS etc we're also fine with storing the key on the
server, why not with DNS?

If you're worried about the key being stolen you can always store it in a HSM
to limit the damage of a server compromise.

------
rascul
Awhile back I started requiring TLS for connections to my mail server. Not
only is this not standards compliant from what I recall, but I've noticed a
disturbing amount of other mail servers that apparently require plaintext
connections. Most notable is password and college application information
which couldn't be delivered to me because their mail servers refused to use
TLS. The college in question was kind enough to look at their logs for me and
see the issue, and ask me to disable TLS to receive the information. Of course
this doesn't solve all the problems. Mail is still stored in plaintext, at
least until I figure out a workable solution for that, and there's probably
still the possibility of MITM attacks, but I feel at least requiring TLS is a
step in the right direction. Until email is finally abolished, anyway.

~~~
ndespres
You set yourself up to miss a fair bit of email that way. Most mail servers I
work with use "opportunistic TLS": attempt TLS for outgoing mail; accept if
offered for incoming mail; selectively enforce TLS on a per-domain basis for
confidential communication to partner banks, law firms, financial firms.

Enforce TLS on your mail server and you're siloing yourself from a large part
of the internet, and unless you're Gmail and your actions carry weight, others
will simply stop emailing you after their mail keeps bouncing.

~~~
rascul
Indeed. It's my personal mail server, and I hate email enough so that
receiving less email (for whatever reason) is not usually a concern of mine.
More important than my dislike of email is organizations which refuse to send
sensitive data over anything but plaintext.

------
snori74
In fact (as the article admits), the encryption is fine and fully effective
against a _passive_ attacker, the problem is that it's not much use against an
active man-in-the-middle. But, that's not something anyone but a NSA or ISP
can easily do between mailservers.

~~~
atmosx
The problem is that most of my emails will end up on Gmail, Yahoo! or Hotmail.
Since nearly no one uses PGP, the emails sit on a google, apple, yahoo,
microsoft server in plain text for any ads or 'gov' company to see and analyze
in bulk.

Until we 'solve' THIS problem, there's no point in discussing what happens in
between IMHO.

~~~
thrownaway2424
Do you think that mail just sits around on "the gmail server" in plain text?

~~~
atmosx
In plain text for any interested party, be it Google, China, the NSA, etc[1].

[1] [http://www.theguardian.com/world/2013/jun/06/us-tech-
giants-...](http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-
data)

------
nwah1
Daniel J Bernstein, designer of DNSCurve, proposed some alternatives to SMTP.

[https://en.wikipedia.org/wiki/Quick_Mail_Transfer_Protocol](https://en.wikipedia.org/wiki/Quick_Mail_Transfer_Protocol)

[https://en.wikipedia.org/wiki/Internet_Mail_2000](https://en.wikipedia.org/wiki/Internet_Mail_2000)

------
teekert
It's indeed not a nice situation, I'd love for my mailserver to insert a line
into the message subject something like: 'TLS not used' when this is the case
(or a plugin for Roundcube (Next?) that colors the subject, how cool would
that be?). Just so I know and are aware of suspicious things. Enforcing TLS
(and valid certs + strong encryption) is just not very practical yet, although
it will definitely not affect mayor players' connectivity (Google, Apple, MS).
Still, a lot of problems will arise, to see how many exactly, this is a rough
indicator:
[http://www.google.com/transparencyreport/saferemail/](http://www.google.com/transparencyreport/saferemail/)

I predict in my group of friends I can receive/sent from/to almost everyone if
I would enfore TLS on my server. Except to/from that one guy that is savvy
enough to have his own domain but hosts his email at a cheap, crappy provider.

~~~
cm2187
A header would probably be more appropriate. Then any client could display it
differently. The problem is that your mail server can only tell that the last
leg of the connection was encrypted, not that all connections from the
sender's client were all encrypted.

~~~
slasaus
But isn't it that in practice most of the time this "last leg" is the only leg
that crosses the internet? Most of the servers I see in the mail headers I
receive are servers in the internal network of the sender. So IMHO transport
encryption still is of real significance against passive attacks.

~~~
cm2187
Actually the first leg (sender client to sender smtp server) is probably the
most at risk of a mitm, as it often goes over wifi.

------
capt_hotpants
A thousand times yes.

PGP and SMIME is perfectly fine for high security scenarios (whistleblowing
and such), in other words for the 0.000001% use case.

For the 99.9% use case, all that regular folks need is for the sending MX to
verify that the recipient MX owns the domain before delivery.

PGP and SMIME with their key-signing parties, government-owned PKI et cetera,
is either wild overkill or so utterly complex that it defeats the purpose for
the 99.9% use case.

\---

That said, you are going to break some of my software with this.

Specifically a SMTP reverse proxy, that looks at the domain part of RCPT TO,
and transparently forwards the SMTP connection to the correct customer's MX
for processing.

It could easily be unbroken again - BUT that would require that Postfix get
their software together and add SNI support to their TLS stack (like all?
other MX software does).

\---

Implementation proposal:

1) Use RCPT domain-part for the SNI hostname.

2) Always try SMTPS port before SMTP port. Always try STARTTLS before
plaintext.

3) Actually verify the certificate, duh.

4) Support a new EHLO header that mimics Strict-Transport-Security exactly.

~~~
Flimm
Actually, even PGP is not fine for high security scenarios. For example, it
doesn't encrypt headers, including the subject line, which I would say is just
as important as an email's body.

~~~
hannob
Some people are trying to fix that:
[https://modernpgp.org/memoryhole/](https://modernpgp.org/memoryhole/)

------
yuhong
Right now I am thinking a HSTS-like solution is the best idea for now, though
I do wish for a DNSSEC2 eventually.

------
rnbrady
Wow, that's an eye opener. Thanks for the write up.

------
abricot
This article motivated me to at least create a self-signed certificate for my
server.

~~~
talideon
One thing to keep in mind if you use Thunderbird is that their certificate
verification library (Mozilla::PKIX) really, really hates self-signed
certificates. So, if you're using a self-signed cert on your mailserver's
submission port or to encrypt IMAP traffic, Thunderbird will simply fail to
work.

Unfortunately, I know of no way around this. I just gave up and started using
Claws in the meantime.

~~~
abricot
I only ever use my server to forward emails for certain addresses. No clients
ever contact it.

------
thrownaway2424
S/MIME also neatly solves the problem.

~~~
silon7
The problem is not encryption, S/MIME works well enough for that.

The problem is you don't have public keys for people you send to.

And there's not a reason for many to get the keys.

I wish I could say "I'll read your unencrypted email tomorrow" (and delay it
from getting to my inbox).

~~~
Tepix
S/MIME actually solves the key problem pretty nicely, every signed mail
contains the certificate that is required to send an encrypted reply. Just
start signing your mails.

~~~
Natanael_L
That's just the TOFU/POP trust model, same as unverified SSH server keys.
Doesn't help against persistent MITM.

~~~
noinsight
Sure it does. The information in the certificate is signed (by the
intermediate CA) and will contain a certificate chain that leads to a trusted
CA and the email address and possibly even the subject's name will be encoded
within the certificate. If you can trust the root CA, you can trust that the
other party is who they say they are.

Then we get to argue whether NSA can get bogus valid certificates from the
commercial CA's... Of course you could roll your own CA but then both parties
need to trust it.

------
mike-cardwell
Also of relevance:

[https://www.mail-archive.com/dane-
users@sys4.de/msg00142.htm...](https://www.mail-archive.com/dane-
users@sys4.de/msg00142.html)

Comcast published TLSA records the other day. So when people like myself who
have enabled TLSA in Postfix send email to Comcast users, the SMTP connection
is guaranteed to be both encrypted, and the SSL cert validated.

------
rc4algorithm
This article suggests that there's no point in having a valid SMTP cert.
However, consider end-users' clients, which store the SMTP domain (i.e. don't
do MX lookups) and connect to it directly. For mail to users on the same email
network, this is the only non-local SMTP hop. Securing this connection also
prevents anyone on the end-user's local network from MitMing.

------
devy
The author only mentioned STARTTLS as the way to secure SMTP. However, there
are at least two other ways to do it:

* TLS Wraper

* Secure Tunnel

And Amazon Web Services Simple Email Service accepts all three approaches.
Granted the latter two may not be supported by a lot of providers, but hey is
that the same thing with browsers securities? We deprecate old MTAs and old
versions of them progressively. Just my two cents.

------
ape4
Can we setup a list of servers that definitely support SMTP STARTTLS. Don't
accept a plain text connection with them.

