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

31–40 of 65 posts

Re: The sad state of SMTP encryption

#31

Post by thrownaway2424 »

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.

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

Re: The sad state of SMTP encryption

#32

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

Re: The sad state of SMTP encryption

#33

Post by Flimm »

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…

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.

Re: The sad state of SMTP encryption

#34

Post by pjc50 »

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…

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.

Re: The sad state of SMTP encryption

#35

Post by capt_hotpants »

pjc50 wrote: post #34
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…

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

Re: The sad state of SMTP encryption

#36

Post by cm2187 »

slasaus wrote: post #27
cm2187 wrote: post #25

Earlier quoted context omitted.

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.

Re: The sad state of SMTP encryption

#37

Post by capt_hotpants »

Flimm wrote: post #33
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…

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?

Re: The sad state of SMTP encryption

#38

Post by capt_hotpants »

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…

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

Re: The sad state of SMTP encryption

#39

Post by Natanael_L »

avian wrote: post #29
Tepix wrote: post #20

Earlier quoted context omitted.

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.

Re: The sad state of SMTP encryption

#40

Post by jcrites »

FiloSottile wrote: post #22
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…

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

Post reply on HN