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.
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.
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
But now, both started offering TLS, just recently it seems.
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.
The downgrade concern mentioned in the post is moot with server-to-server SMTP because we have to intentionally allow downgrades to account for old mail servers.
The other concerns with STARTTLS still apply to server-to-server SMTP, but since our only options for server-to-server SMTP are STARTTLS or no encryption at all, we have to just use STARTTLS here.
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.
There has been suggestions to provide standard certified secure email (100% TLS always required).
Edit, one link as example: https://www.nmillc.net/SMX.html
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.
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.
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.
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.
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.
Of course, if you just enable it.
http://www.sami-lehtinen.net/blog/securing-email-transport-s...
Unfortunately even many large providers use invalid (non verifiable) certificates. Unless you of course install their public key locally and verify against it.
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?
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.
STARTTLS on port 25 is vulnerable to active MITM anyway, so having your certificate signed by a big CA doesn't really get you much. For delivery over port 465 it makes sense, but an active MITM could still block your connection and see if you fall back to STARTTLS on 25. Fastmail have a good summary of the current situation[0]. And, as Sami_Lehtinen said, many servers out there probably have self-signed certs.
Even if you validate certificates an active attacker can return false MX records and direct the sending MTA to connect to an attacker-controlled server which presents a perfectly valid certificate.
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.
"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.
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.
The message envelope cannot be encrypted, so traffic analysis or other kinds of tampering can still be performed on GPG- or CMS-encrypted emails. It'd be like doing client-side encryption in JavaScript, but all of the HTTP requests and responses go out in the clear. Message encryption and transport encryption are complimentary. They protect against different kinds of attacks.
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?
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?
There's no solution exactly like HSTS, though DANE+DNSSEC provides a solution to the downgrade (and cert validation) problem. Postfix has an implementation. Unfortunately it requires DNSSEC, which has issues.
DANE should solve this eventually; in the meantime I have a hardcoded smtp_tls_policy_maps which I've populated with domains that I frequently email and which the logs show support TLS.
40 comments
[ 4.4 ms ] story [ 71.2 ms ] threadBut now, both started offering TLS, just recently it seems.
https://www.agwa.name/blog/post/starttls_considered_harmful
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.
The other concerns with STARTTLS still apply to server-to-server SMTP, but since our only options for server-to-server SMTP are STARTTLS or no encryption at all, we have to just use STARTTLS here.
http://serverfault.com/q/623692/120791
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.
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.
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.
And why does it make encryption pointless? The traffic IS encrypted, server to server. Are you afraid someone hijacked a domain?
[0] https://www.fastmail.fm/help/technical/ssltlsstarttls.html
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.
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.
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.
> Who cares?
uh, the more than a billion (maybe more than two billion) people who use email and get their email swept up in casual dragnet surveillance otherwise?
Also, EFF is working on a project like HTTPS Everywhere but for SMTP encryption: https://github.com/EFForg/starttls-everywhere