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

51–60 of 65 posts

Re: The sad state of SMTP encryption

#51

Post by talideon »

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.

Re: The sad state of SMTP encryption

#52

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

Re: The sad state of SMTP encryption

#54

Post by cm2187 »

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

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

Re: The sad state of SMTP encryption

#55

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

Re: The sad state of SMTP encryption

#56

Post by atmosx »

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?

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

Re: The sad state of SMTP encryption

#57

Post by atmosx »

xvilka wrote: post #41
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.

Projects like a MailPile [1] could help here. [1] https://www.mailpile.is/

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

Re: The sad state of SMTP encryption

#58

Post by hannob »

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.

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

Re: The sad state of SMTP encryption

#60

Post by gwu78 »

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…

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

Post reply on HN