
Email encryption in transit - Sami_Lehtinen
https://www.google.com/transparencyreport/saferemail/
======
teekert
I have been using checktls.com to see if I had set my personal mail server up
in the correct way. While testing some other providers: gmail, me.com,
live.com I found that the latter two did not provide TLS (this was about 4
months ago), I even made an Ask HN:
[https://news.ycombinator.com/item?id=7708882](https://news.ycombinator.com/item?id=7708882)

But now, both started offering TLS, just recently it seems.

~~~
Sami_Lehtinen
Outlook, Hotmail, Live and Yahoo lacked TLS until very recently.

------
pyre
If you expand the inbound graph out to "90 days" or "1 year" there seems to be
a pattern of spikes. I'm curious what causes these. I don't think that they
are caused by volume of email spiking, because it's graphing the percentage of
incoming email that is encrypted.

~~~
claudius
These seem to be weekends. Maybe consumer-oriented email services (Outlook,
Google, whatever) use TLS more often than those built for businesses? While
this doesn’t make much sense, it only takes a couple of providers to switch a
large number of consumers to encrypted email transports, whereas each little
server operated for each little business has to be switched individually.

~~~
giovannibajo1
It makes sense, as businesses are usually trailing in adoption of best
practices.

------
nly
STARTTLS is vulnerable to active MITM downgrade attack. Are there any
equivalent techniques to HTTP Strict Transport Security ("Remember me and
don't talk to me over an insecure protocols again") for SMTP?

~~~
bitJericho
I think DKIM/SPF resolves that. The recipient (spf) or the sender (DKIM) of
the email decides what servers are allowed to send out mail for a domain.

~~~
capnrefsmmat
That doesn't stop a MITM impersonating the recipient of the message; it just
stops someone impersonating the sender.

~~~
nly
It doesn't even stop that, since we're talking about a MITM between a
legitimate sender and receiver.

~~~
bitJericho
Well I guess you'd know about the MITM after the attack, since the email could
get rejected if it comes from a bad IP. But yes you guys are absolutely right.
PGP ftw?

------
jackweirdy
This was also posted in response to a SE question I asked about requiring
STARTTLS on incoming email:

[http://serverfault.com/q/623692/120791](http://serverfault.com/q/623692/120791)

~~~
baudehlo
I posted that response :)

The members of MAAWG often keep and talk about these sorts of statistics too,
although I wasn't able to find anything public (and I'm no longer a member so
can't search the private archives any more). One thing worth bearing in mind
is that Google's traffic is probably heavily biased towards consumer email.
Business traffic may have a different profile.

------
eghri
It would be great if Gmail could provide a small notice on whether the
email(s) you are sending to will be encrypted or not (just like the lock for
HTTPS). I will probably still send the unencrypted email in most cases, but it
would make you reconsider putting too much personal information in the email.

~~~
mseebach
There's very little utility for the enduser, and a lot of confusion to be had
for all but the very most technical users.

Just because the inbound server uses TLS, it doesn't mean that the IMAP/POP
server servicing the recipient does. He might very well download his email
unencrypted on Starbucks wifi, and you're none the wiser for it.

The bits of the internet closest to the users are the ones most critical to
secure. The backhaul between gmail.com and outlook.com should be encrypted
(and is, so that's good), but it's very much a secondary concern to securing
the enduser connections.

~~~
magicalist
What? The connection between gmail.com and outlook.com is exactly what the GP
is talking about.

I agree that user confusion might result in a false sense of security, but
it's ridiculous to assert that because there may be other weak links that
"there's very little utility" to ensuring that email is sent over an encrypted
connection between servers. In fact you could make the same claim about the
TLS lock icon in the browser, as all you know is you have a secure connection
to that server, you have no idea how they're actually treating the data you
send to them.

I like the GP's idea. Have a little secure red/green based on an attempt to
negotiate a connection with the destination server(s) while you're writing the
email, then, if the server says it supports encryption, _only_ send the email
over an encrypted connection, else show an error message of some sort. Not for
all users at first, maybe, but SMTP over TLS is obviously getting common
enough now that it should be more or less required soon.

------
IgorPartola
I was hoping they'd provide some stats on people that use GPG/PGP. Remember
folks, that while GMail may be able to collect some of these stats, nothing is
preventing me from setting up forwarding from a "secure" email host to an
insecure one. So you never really know whether that password to the FTP server
you are sending me is actually ever transmitted in cleartext or not.

~~~
Sami_Lehtinen
That's major problem with any secure system. Even if parts of it would be
secure, there's no guarantee what so ever that rest of the system is secure. I
see astounding examples about that almost daily. Security is high, until some
intergration channel uses plain text http or ftp for data transport over
internet, with weak or non existing authentication. In worst cases, using the
same credentials you can also access a ton of other data, because only
directory separation is used for different data sets. In some cases, the same
credentials can be also used for remote desktop / SSH logins. Which makes me
smile and cry every time that happens. Yes, even high profile businesses do
those ridiculous fails, repeatedly. In many cases, they don't even bother to
fix those, when I'm letting them know about insecure system configuration.

------
higherpurpose
Any truth in this?

[https://www.agwa.name/blog/post/starttls_considered_harmful](https://www.agwa.name/blog/post/starttls_considered_harmful)

~~~
omh
From that article:

 _Unfortunately, the SMTPS port is only used for the submission of
authenticated mail by mail clients. Opportunistic encryption between SMTP
servers, which is extremely important for preventing passive eavesdropping of
email, requires STARTTLS on port 25_

So for the sort of thing that Google are talking about STARTTLS is the only
option.

Some of the disadvantages aren't such a big deal for large-scale server-to-
server transport. But protocol downgrade attacks should certainly be a worry.

------
IvyMike
Someone else mentioned this the last time this was posted, but the 99% and the
99.99% stats are in some ways scarier than the 50% and 0% sites.

------
calpaterson
Do email daemons validate certificates now? I thought they didn't - which
would make encryption fairly pointless

~~~
Sami_Lehtinen
Of course, if you just enable it. [http://www.sami-lehtinen.net/blog/securing-
email-transport-s...](http://www.sami-lehtinen.net/blog/securing-email-
transport-starttls-postfix-ca-certificates-fingerprint-authority)
Unfortunately even many large providers use invalid (non verifiable)
certificates. Unless you of course install their public key locally and verify
against it.

~~~
teekert
Unfortunately? I also use unverified certificates on my own mail server. I
don't want to be requesting certificates or signing for every time I set up a
mail server.

And why does it make encryption pointless? The traffic IS encrypted, server to
server. Are you afraid someone hijacked a domain?

~~~
drdaeman
Because unauthenticated encryption is no good. It only protects communications
against passive attackers (mere observers), which, I think, is generally
considered to be far from sufficient. Meanwhile, it creates a false sense of
security, which isn't a good thing.

------
jingo
"... during transport"

Who cares? I'm more interested in knowing the percentage encrypted _before_
transport.

"During transport" requires authentication; otherwise all bets are off.

"Before transport" at least minimizes the damage if the email is sent to the
wrong recipient.

I have yet to see an authentication mechanism that looks "trustworthy"
(decentralized and simple), other than a pre-sharing some identifier face-to-
face.

~~~
Sami_Lehtinen
"Before transport" at least minimizes the damage if the email is sent to the
wrong recipient.

Doesn't really help, because most of email clients do encryption
automatically. Which means that then the message is encrypted to wrong
recipient as well.

~~~
jingo
Well, that's another type of error (human error). And TLS will not address
that type of error either.

I was referring to the case where the email is redirecting to (or through) an
unintended recipient.

Before my comment is further misinterpreted, let me make clear:

I am not saying "Do not use SSL/TLS." By all means use it; regardless of the
bugs, the complexity and the lack of an acceptable authentication mechanism.

But encrypting before transport is even more important, IMO. And so that is a
more interesting statistic.

The two are not mutually exclusive.

Not to mention one could use SSH for encryption "in transit". It has better
authentication than SSL/TLS, but that's only my opinion.

------
lucio
A picture is worth... what's with the sailboat in the drawing? the only prying
eyes are overseas?

~~~
Someone1234
The pipe between the two land masses is even less subtle. Very interesting
message there, I definitely noticed it too.

~~~
SloopJon
I think the picture is supposed to be generic, but it kind of looks like
Florida and Cuba.

