Live data from Hacker News

Email encryption is here – use STARTTLS everywhere

dwheeler.com

11–20 of 74 posts

Re: Email encryption is here – use STARTTLS everywhere

#11
The site has a link to the starttls everywhere site right at the top - but it's also worth mentioning that the regular 'certbot' client for https everywhere can also be used to create certificates for your own smtpd. The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process.

using certbot:

sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com

where mail.mydomainname.com is whatever is the full hostname of your MX.

then a pretty typical postfix configuration blob:

# TLS (SSL) private and public keys

# obtained from certbot-auto in /etc/certbot/

# sample CLI to obtain new cert

# sudo ./certbot-auto certonly -v --standalone --standalone-supported-challenges http-01 -d mail.mydomainname.com

smtpd_tls_CAfile=/etc/letsencrypt/live/mail.mydomainname.com/fullchain.pem

smtpd_tls_cert_file=/etc/letsencrypt/live/mail.mydomainname.com/cert.pem

smtpd_tls_key_file=/etc/letsencrypt/live/mail.mydomainname.com/privkey.pem

# TLS (SSL) configuration

smtp_tls_security_level=may

smtp_use_tls=yes

smtpd_use_tls=yes

smtpd_tls_loglevel=1

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3

smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client.

Re: Email encryption is here – use STARTTLS everywhere

#12
post #10
post #7

Earlier quoted context omitted.

In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.

That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!

Keeping your own server up at several nines of uptime is a non-trivial endeavour.

Re: Email encryption is here – use STARTTLS everywhere

#13
post #9

So this is kinda like the HSTS preload list, but includes MX server names, and is supposed to be updated every 48 hours. Couldn't we just put this in DNS?

That would be fine, too, and reflects in part what MTA-STS is trying to do.

A point that may be obvious, but I would like to make explicit, is that unlike on web, end-users have no good way to express whether they prefer security over deliverability on a connection, which makes downgrade attacks more difficult to deal with. Everyone defaults to preferring deliverablity (falling back to plaintext). In the absence of user intent, it's more important for an email sender to know the recipient mailserver's intent: what level of security should they expect? This can be achieved at varying degrees through DANE, MTA-STS, or a "HSTS Preload List" equivalent for email, but there is currently no reliably deployed standard for this.

(edit: something I forgot to mention: of course, you'd have to trust the initial DNS lookup as well)

Re: Email encryption is here – use STARTTLS everywhere

#14
post #12
post #10

Earlier quoted context omitted.

That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!

Keeping your own server up at several nines of uptime is a non-trivial endeavour.

Using configurations that provide redundancy is quite trivial. Also, what is the point of having several nines of SLA on a mailserver? Emails get retried a number of times before they are considered undeliverable.

Re: Email encryption is here – use STARTTLS everywhere

#15

The site has a link to the starttls everywhere site right at the top - but it's also worth mentioning that the regular 'certbot' client for https everywhere can also be used to create certificates for your own smtpd. The easiest way is just having the sudo ability to temporarily open port 80 for the challenge/response process. using certbot: sudo ./certbot-auto certonly -v --standalone --standalone-supported-challeng…

Thanks for the plug. The same developer at EFF is working on both STARTTLS Everywhere and Certbot Postfix integration. :-)

(Anyway, the most significant difference between the two is that STARTTLS Everywhere can also enforce certificate validation on recipient sites that request it, which Postfix won't otherwise do.)

Re: Email encryption is here – use STARTTLS everywhere

#16
post #10
post #7

Earlier quoted context omitted.

In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.

That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!

Maybe if you live in a country who's IPs are deemed "trustworthy"

Re: Email encryption is here – use STARTTLS everywhere

#17
post #10
post #7

Earlier quoted context omitted.

In general, if a government asks your provider for access to your emails then will hand them over. The only way to mitigate this threat is to use e2e encryption or host the email server on premises but then you start encountering deliverability issues.

That's FUD. If a system is correctly set up, you'll have no deliverability issues. Edit: srsly guys, HACKER news people say that it's impossible for a person to have a proper mailserver set up? That's hilarious, if not sad!

This is just not true.

The Internet is full of stories of people having trouble with large email providers (notably Google and Microsoft) accepting self-hosted users' mail. A self-hosted setup's IP starts with 0 reputation (or worse, depending on who owned the IP address beforehand) and will face throttling and outright blocking for a painful amount of time.

Furthermore, if you forward your email to e.g. a Gmail inbox, any spam sent to your address will go towards lowering the reputation of your forwarder, meaning that someone just has to send you a lot of spam to get your forwarder blocked from Google servers.

SPF, DKIM, DMARC and TLS all cannot mitigate the above.

Re: Email encryption is here – use STARTTLS everywhere

#18
What we need next is a widely adopted standard of end-to-end opportunistic encryption, similar to Signal. PKI and PGP are too complex for end users.

The problem that prevents such a standard from ever taking off is that, unlike TLS, there is zero interest from major providers to push end-to-end encyption, because they absolutely need access to the plain text for commercial reasons. So they advertise STARTTLS as "email encryption". By that token, CDMA and GSM are "email encryption" as well, it's not like they push the plain text naked over radio.

Re: Email encryption is here – use STARTTLS everywhere

#20
post #8
post #2

Sure, STARTTLS is better than nothing, but your email provider still reads your email. When we talk about email encryption, we mean end-to-end encryption.

I am my own provider. It's really not that hard to configure a mail server. Other peoples' providers, however... so I tried using PGP. It's somehow manages to be more difficult to use than configuring and running your own mailsystem which doesn't deliver straight to gmails' spam folder, but I digress; but then my emails are at mercy of the end devices: who knows if outlook doesn't send a plaintext email home as "tele…

Also all of your emails get kicked to spam when you host your own.
Post reply on HN