Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The sad state of SMTP encryption

blog.filippo.io

Post reply on HN
Print view View original

41–50 of 65 posts

Re: The sad state of SMTP encryption

#41

Post by xvilka »

atmosx wrote: post #7
snori74 wrote: post #5

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.

Projects like a MailPile [1] could help here.

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

Re: The sad state of SMTP encryption

#42

Post by thrownaway2424 »

capt_hotpants wrote: post #35
pjc50 wrote: post #34

Earlier quoted context omitted.

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

Re: The sad state of SMTP encryption

#43

Post by caf »

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

Re: The sad state of SMTP encryption

#44

Post by Bino »

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…

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

Re: The sad state of SMTP encryption

#45

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

Re: The sad state of SMTP encryption

#46

Post by ndespres »

rascul wrote: post #45

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…

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.

Re: The sad state of SMTP encryption

#47

Post by rascul »

ndespres wrote: post #46
rascul wrote: post #45

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…

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

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.

Re: The sad state of SMTP encryption

#48

Post by wolf550e »

thrownaway2424 wrote: post #31
atmosx wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: The sad state of SMTP encryption

#49

Post by noinsight »

Natanael_L wrote: post #26
Tepix wrote: post #21

Earlier quoted context omitted.

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.

Re: The sad state of SMTP encryption

#50

Post by talideon »

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

Post reply on HN