The sad state of SMTP encryption • Hacker News Board

Re: The sad state of SMTP encryption

#61

Post by Tepix » Thu, Nov 12, 2015, 2:14 PM UTC

talideon wrote: post #50

Tepix wrote: post #11

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 als…

> 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 de…

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.

Re: The sad state of SMTP encryption

#62

Post by teekert » Fri, Nov 13, 2015, 8:55 AM UTC

cm2187 wrote: post #25

teekert wrote: post #9

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 mayo…

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.

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

:)

Re: The sad state of SMTP encryption

#63

Post by capt_hotpants » Fri, Nov 13, 2015, 4:11 PM UTC

caf wrote: post #43

capt_hotpants wrote: post #32

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…

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.

Re: The sad state of SMTP encryption

#64

Post by abricot » Sat, Nov 14, 2015, 9:58 AM UTC

talideon wrote: post #51

abricot wrote: post #17

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

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.

Re: The sad state of SMTP encryption

#65

Post by capt_hotpants » Mon, Nov 23, 2015, 11:45 PM UTC

thrownaway2424 wrote: post #42

capt_hotpants wrote: post #35

Earlier quoted context omitted.

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 rece…

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.