The sad state of SMTP encryption | Hacker News Reader

The sad state of SMTP encryption

blog.filippo.io

164 pointsFiloSottile62 comments

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)

Thanks!

Not sure I made that point clearly but I'm not saying that performing validation against the MX target is wrong. However it requires the MX to be authenticated (i.e. signed with DNSSEC), otherwise the attacker can just falsify the MX and have mail delivered to a server for which it has a valid certificate, making validation useless.

Some additional arguments against DNSSEC and a FAQ from Thomas Ptacek:

http://sockpuppet.org/blog/2015/01/15/against-dnssec/

http://sockpuppet.org/stuff/dnssec-qa.html

I was not familiar with that EFF project. Looks like an interesting starting point. I wonder if, rather than maintaining a central configuration file, domain owners could vend configuration through canonical URLs on each domain, like https://example.com/.smtp-ssl for example.com - essentially bootstrap the security through another protocol that's more mature. (This could have the effect of using the existing CA system rather than relying on a government-controlled PKI.)

MTA's are beginning to support DANE, now let's wait for some larger companies (google, yahoo, office365) to jump on the bandwagon to publish TLSA records...

http://www.postfix.org/TLS_README.html#client_tls_dane

https://github.com/Exim/exim/blob/master/doc/doc-txt/ChangeL...

http://wiki.halon.io/DANE

> 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)

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.

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.

"In fact, before DANE arrived on the scene, there was hardly a good reason to deploy it [DNSSEC]."

As I recall, the problem DNSSEC aimed to solve when it was re-proposed (it failed mutiple times previously), circa 2008, was cache poisoning. That problem can be solved other ways besides using DNSSEC under the control of third parties. Of course, today we rarely hear much about cache poisoning when DNSSEC is brought up. Instead the discussion usually revolves around other problems such as the CA system or spam. What's funny about this is that the proposed use of DNSSEC only enforces another system where potentially untrustworthy third parties are in control.

Is it a coincidence this blog post was written by someone employed by Cloudflare? Another company tied to the DNS "business". This is the third post pushing DNSSEC from Cloudflare to reach the HN front page in the last month.

Will there be a fourth?

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.

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.

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.

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.

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.

Even if you run your own mailserver, you're not in control unless it's a dedicated server. On a VPS you may be spied upon by your ISP without standing a chance of noticing it. Luckily there are now ISPs that let you rent a dedicated server for 6€ a month (or just host it at home on something like the Raspberry Pi 2 and use a minimal VPS just to tunnel the traffic to it from its non-dialup IP address so email actually works).

I was able to solve this problem by setting up a relay on a remote and international vps, and then requiring an encrypted connection between that server to my home network. If the link was active, the mail would go through. If the link was inactive, it would queue up. That way I didn't need as reliable of a home network and could rely on the datacenter to maintain uptime. For a couple more dollars you could get a second VPS for even better uptime.

It doesn't solve it but it does reduce it. If smtp is encrypted only the US can read your correspondance. If smtp is unencrypted any country and telco operator through which your data transit can read your correspondance.

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

Rogue Google employee can read your mail (a fireable offense, but possible). US Government can compel Google to share your mail.

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-...

Projects like a MailPile [1] could help here.

[1] https://www.mailpile.is/

Yes, I have high hopes for mailpile! :-)

If you can see a DNS request going out and can send a fake response that arrives before the real one, you have enough resources to pull off a MITM.

Yes, but unless you're the ISP that's not going to be possible surely? Mailservers typically don't run over wireless.

I was responding to the idea that being a man-in-the-middle is significantly more difficult than being a passive eavesdropper.

If you're already a passive eavesdropper, all you need is the ability the send a DNS response and you're a man-in-the-middle.

There are many other attackers besides NSA and your ISP who are on-path. Anyone on the same network as the sender or receiver will do. There are many servers who are on the same network with compromised boxes (think cohosting, your home network with IoBT devices, typical corporate intranet, etc).

It's a real problem. If you visit countries like Egypt, you will experience STARTSSL-stripping every day.

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/Internet_Mail_2000

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/

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.

This should be pretty easy to do with a SIEVE filter rule: If the Received: line inserted by your mail server doesn't contain "using TLS..." you put a prefix into the mail subject.

Not all MTAs do this, FWIW.

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.

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.

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.

http://techcrunch.com/2015/11/12/gmail-will-soon-warn-users-...

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.

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.

Good point.

S/MIME might also have some dependencies on PKI that in some scenarios could make it unsuitable for high security scenarios?

Some people are trying to fix that: https://modernpgp.org/memoryhole/

What is the 99% use case? Most people's email has one endpoint at either a big cloud provider or an employer, both of which are examining it at rest.

Good question!

For me personally, I'm not too worried about the NSA. But I do think it is quite silly that Gmail and Outlook has a little lock icon to indicate that security is ON, while the first thing that happens when you click Send is that your email is whizzed over half the internet in plaintext.

For organizations and corporations, I imagine they would very much like to be able to verify the identity of the receiving organization before delivering possibly sensitive email.

(The sender identity is already authenticated via DKIM.)

For organizations that subscribe to these cloud services (like Google Apps, or hosted Exchange) there are settings to enforce the use of TLS on both inbound and outbound. For example https://support.google.com/a/answer/2520500

If you read the fine print in bullet #8, you'll discover that there is, per default, no validation of the presented certificate at all.

Without proper certificate validation, the encryption step is cryptographically worthless. Anyone can MITM the traffic just by presenting a random certificate to the sender.

5) Slap a nice name on the feature-set, so products can advertise it. (An important step often forgotten by engineers ;-))

You are assuming that only one RCPT is being sent in the session.

(What does happen with your reverse-proxy when someone opens up a session and sends two mails, to two different customers?)

Currently, this happens:

   if hostname != target {
      downstream.Write([]byte("452 Different domain, please reconnect and deliver separately.\r\n"))
      continue
   } else {

As a side-effect, email to the secondary domain is slightly delayed.

It is a full proxy, in the sense that it sees all of the traffic, so technically it could de-multiplex and spool to two different targets at the same time for the duration of the current email.. Hasn't been a noticeable problem so far. But it would be nice to add at a later point in time. If/when someone complains, probably.

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

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

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

Why not get a free real certificate form letsencrypt or startssl?

Because as the article says, it is as good as a CA-signed one, is easier to make and can have a long validity period.

StartSSL limits you to one year and Let's Encrypt is really focused on certificates for HTTPS (their ACME protocol AFAIK requires a handshake through HTTPS).

Once you have LE certs, you can reuse them for anything on the same domain AFAICT. Might need some configuration changes though to get a cert issued for something like a dedicated email server subdomain.

to be honest a commercial SSL certificate costs the price of a coffee per year https://cheapsslsecurity.com/

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.

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

S/MIME also neatly solves the problem.

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).

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.

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

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.

Also of relevance:

https://www.mail-archive.com/dane-users@sys4.de/msg00142.htm...

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.

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.

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.

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

Reply on news.ycombinator.com