
Email encryption is here – use STARTTLS everywhere - severine
https://www.dwheeler.com/blog/2018/07/24/#email-encryption
======
bumholio
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.

~~~
rakoo
It's not a standard, but it's there: autocrypt
([https://autocrypt.org](https://autocrypt.org)) aims to make end to end
encryption as easy as possible. It's using PGP underneath but the whole idea
is to hide key management (the real pain point) from the user. It's a long
term initiative, divided in multiple levels of "compliance" that gradually
break compatibility with existing systems more and more. Level 1 is there
already, with some implementations.

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

~~~
arpa
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 "telemetry"? Same thing about
chrome with all the extensions for using PGP... I mean, security is hard as-
is, but security of an ubiquitous thing, especially when people have been
conditioned to undervalue security and privacy, is a lost cause. It's best to
treat emails as being in the same category as phone calls, conversations in
subway and sms'es - public.

~~~
selectodude
Also all of your emails get kicked to spam when you host your own.

~~~
Erlich_Bachman
Not true. This might be happening if you are trying to host a server on your
domestic internet connection, those IP ranges are usually banned in spam
filters. But you can easily host your e-mail server on a real datacenter
server or something similar, and you'll have almost no problems with spam
filtering. (In fact many companies and even individuals already do this and
have done this for long time.)

~~~
loup-vaillant
> _Not true. This might be happening if you are trying to host a server on
> your domestic internet connection, those IP ranges are usually banned in
> spam filters._

This is pretty much what "hosting your own" _really_ means. Having SSH access
to some virtual machine somewhere is much better than letting gmail read all
your mail, but it's still isn't self hosting. You could still use the remote
host as a mere relay, but it's still not ideal.

Real self hosting means having your box at home, sending and receiving mail
directly. And _that_ is effectively impossible. Self hosting is dead. I'm not
sure how we could resurrect it.

~~~
yrro
Host at home, relay via an IP address owned by a hosting provider. Pragmatism
meets idealism.

Of course, I don't do this because I don't want to rely on my consumer
internet connection or domestic electricity provider, and my flat is too small
for a rack anyway. Also the noise, electricity bills and waste heat play a
part.

Some things are best done centrally. I am happy with servers in the cloud, I
really don't miss having to travel half way across the country to replace a
hard drive...

~~~
loup-vaillant
> _Host at home, relay via an IP address owned by a hosting provider._

As I said, "You could still use the remote host as a mere relay, but it's
still not ideal". And by the way, as much as I'd like to host my email at
home, I still gave in somewhat and use a remote virtual machine (at
[https://gandi.net](https://gandi.net)).

> _my flat is too small for a rack anyway. Also the noise, electricity bills
> and waste heat play a part._

You need less than 5W, a small shoe box worth of space, and no fan at all to
host your email at home. R-Pi, Sheeva plug… A web site with moderate traffic
might be more problematic. But we're nowhere near a _rack_. For remote
hosting, you don't need more than a fraction of a CPU core.

Reliability, though, _that_ can be a real problem. And a big reason why I
still use my virtual hosting provider. I'd love a redundant setup, where if
something goes down, the backup takes over, and notifies you about needing to
replace a piece of hardware. (Of course, it should be plug & play so my
grandma could do it… one can dream.)

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

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

~~~
rhizome
Thanks for calling that part out!

------
__david__
So I support more encryption everywhere, but this is acting like there's
something new? I know I've been using STARTLS on SMTP for almost 20 years… Am
I missing something?

~~~
jlgaddis
> _... there 's something new?_

The "STARTTLS Everywhere" project [0] -- the one thing this entire article is
talking about -- is what's new.

> _... I 've been using STARTLS on SMTP for almost 20 years ..._

That's great -- I have too -- but I have some bad news for you: not everybody
else has been! (I know, right!?)

The EFF is simply trying to bang the drums to get everyone's attention and
then convince those that aren't already using STARTTLS (everywhere, hence the
name) to consider doing so.

The good news, for you, is that you're already done. There's nothing for you
to do, unless you want to add your domains to the "policy list" so that others
who are participating won't send mail to you unless encryption is in use.

Fortunately, the EFF has already written about this extensively [0], so
there's no need for me to rehash all the details (coincidentally, that same
exact web page is also reachable by clicking on the first link in this
article).

[0]: [https://www.starttls-everywhere.org](https://www.starttls-
everywhere.org)

~~~
apple4ever
It seems to be dead.

I submitted my domain and it’s not on the list, and there has been no
communication about why or why not (given that it passes their security
checker and requirements).

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

~~~
sydli
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)

~~~
fowl2
What would be more/also interesting would be a way of expressing this intent
by a _sender_.

Seems like (with absolutely no thought here) a new header could me minted for
this - eg. "Transport-Security: Require". Tough part as usual would be getting
MTA and client support, but switching to a per message approach would at least
allow incremental rollout - and critically I think - allow introspection by
following bounces.

------
sleavey
I have my mail server require a TLS connection to a host before sending mail,
but perhaps 2% of the time I get my mail bounced by the target server because
it doesn't support it, including my old university. It's really crazy that a
20+ year old, standard technology is not literally everywhere, especially in
big organisations.

Incidentally, that same university in the past year started injecting footers
into people's emails, so I guess their primary focus is neither privacy nor
security.

~~~
walrus01
At present not allowing plaintext port 25 will break a lot of email
functionality, there are a ton of old and poorly set up mx out there. I have
my postfix setup as "may" for TLS, not required.

~~~
sleavey
But for actively maintained servers, could they not be configured to support
TLS for clients that request it without breaking plaintext email for old
clients? I'm trying to understand whether supporting old clients really means
not supporting encryption features for up-to-date clients.

~~~
walrus01
I was referring to server-to-server mail exchange.

Yes, this is how my server is. When exchanging smtp with another domain's mx,
if that other smtpd will not do TLS, it sends plaintext mail. For _clients_
submitting mail via smtp with auth, such as thunderbird on my desktop PC, of
course it does TLS1.2.

------
dmix
Between this and SMS, the NSA (et al) had a gold mine of data when they
directly tapped the lines.

I remember reading they were really upset when this email providers started
using this by default... always a good sign when warrantless/dragnet
surveillance is made harder.

------
walrus01
I really can't agree with this part:

> The STARTTLS Everywhere project has created a “STARTTLS Policy List” where
> supporting organizations can assert that they always use STARTTLS using a
> valid certificate. Organizations should join that list and check that list
> before they send email.

We don't need a new separate place to publish the TLS ability of our mx. This
can be done with a txt record in the DNS zonefiles same as spf.

It would need some sort of consistent rfc-guided format for what TLS policy
re: downgrades, port 25 plaintext, etc, that you want to publish.

Not too dissimilar from publishing an HSTS policy, but done by the
authoritative nameservers for a zone rather than on an individual httpd.

------
AndyMcConachie
For folks interested in this subject I highly recommend Viktor Dukhovni's talk
he gave at ICANN 61 on SMTP STARTTLS/DANE.

[https://mail.sys4.de/pipermail/dane-
users/2018-March/000445....](https://mail.sys4.de/pipermail/dane-
users/2018-March/000445.html)

He also runs stats every month on DANE adoption.

[https://mail.sys4.de/pipermail/dane-
users/2018-June/000460.h...](https://mail.sys4.de/pipermail/dane-
users/2018-June/000460.html)

~~~
jlgaddis
Unfortunately, DANE relies on DNSSEC, and that's the biggest barrier to
widespread adoption that DANE has.

------
Sami_Lehtinen
Interestingly services like Outlook and Hotmail simply fail certificate check.
Maybe TLS is just too hard, even for companies like Microsoft.

------
drudru11
It would be better to have a TLS connection right at the start. STARTTLS is
less secure. Why hasn't this happened for SMTP?

~~~
mike-cardwell
Because it's not backwards compatible, and would prevent delivery of a large
amount of email.

We just need a way for domain owners to signal that their domains definitely
accept email over STARTTLS. At that point, senders which recognise those
signals can start to enforce that mail which they send to those domains MUST
use STARTTLS. Fortunately, those signalling methods are beginning to rise to
the surface. We have MTA-STS, and now also a preload list thanks to StartTLS
Everywhere.

~~~
drudru11
All you need is another port in addition to the regular SMTP port. They are
not mutually exclusive.

~~~
mike-cardwell
That is completely insecure. A MITM would just block access to the tls-on-
connect port, forcing the sending host to retry on port 25, where they would
strip the STARTTLS advertisement.

Unless you're recommending to not fall back to port 25 after a failed
connection to the tls-on-connect port. In which case, see the comment you were
replying to where I said it would be backwards incompatible.

Both of the solutions I mentioned are backwards compatible, and protected from
a similar downgrade situation.

~~~
drudru11
Right, I should have said that I was recommending not ever sending on 25. The
STARTTLS mitm is just too easy for large attackers.

IMHO, being backwards compatible is necessary for a transition period. The
messaging to SMTP operators should be... get on board, or you are going to
start losing mail in 1 year.

Even Chrome is going to show all http as insecure in the very near future.
Which reminds me... I need to get all my sites upgraded.

