This isn't really new news, but improperly configured mail services result in lots of privacy holes across the Internet.
STARTTLS is used to upgrade an unencrypted connection to an encrypted SSL/TLS connection. The problem is that if the upgrade fails, many mail clients will proceed to send mail on the unencrypted connection.
For any sysadmins (technical info):
Unfortunately, the situation is somewhat sticky. I suggest reading carefully the TLS/SSL section of https://wiki.debian.org/PostfixAndSASL as well as the STARTTLS RFC http://tools.ietf.org/html/rfc2487
Public email servers should not require STARTTLS (that is, encryption) on port 25 (smtp). Furthermore, there is no guarantee that all of the mail servers during transit of an email use encryption. Thus, you should assume your email is transmitted unencrypted, until a better solution emerges. You can always use OpenPGP to encrypt the body of your email, which should become commonplace shortly after Hurd achieves market dominance.
Editors Note: How to articles for various flavors of Microsoft Exchange can be found at MSExchange.org.
(Score: 2) by ikanreed on Monday November 02 2015, @01:50PM
This is a STARTTLing revelation! Failover to unencrypted is a terrible design.
(Score: 5, Informative) by frojack on Monday November 02 2015, @04:23PM
We covered this quite extensively, some months ago.
At the time the story was about some ISPs stripping off the indication that the sender requested STARTTLS, or that the smpt server supported it, causing the mail to be transported in the clear.
But STARTTLS has always been simply a request, and not a demand, and even the relevant RFC states it is not mandatory. (Yean, I got modded to hell for pointing that out back then too).
If you use secure imap, or secure pop, you connect via different ports (993 and 465) and encryption is not optional. Mail will either travel encrypted or not at all. Google, Yahoo, Apple, Yandex all use this method.
At least for the first hop, mail and credentials are encrypted.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by edIII on Monday November 02 2015, @08:08PM
Well, you're +4 Informative now.
The reason why the next ones may not be as likely to be encrypted is backwards compatibility, and IMO, a paradigm that is to deliver the mail at nearly all costs. All of the timeouts, waits, and retries seem to be for a system that is not very robust or reliable at all. About the only thing that can take mail servers out for 4 days is DNS errors. Otherwise, setting up redundant mail servers isn't terribly difficult or expensive these days. I believe you could operate a 15 user mail server easily for $5/month probably. I'm spending $30, but that's redundant servers, proxies, and my extended family on it. The real problem I guess is that not many people get to far into SMTP/IMAP beyond simple web based wizard configurations, and completely forget to administrate at all.
I don't even have the option to require all SMTP traffic to be encrypted, just that client connections be encrypted. It would take somebody like Google to start blocking all unencrypted mail traffic to their servers to make a real change. That might allow smaller entities the justification they need to adopt the same policy, which my current mail server doesn't even support *yet*. It's stupid, but I know it will effective to tell an executive, "But they can't email Google either. Of course it's their screw up".
The times I've tried to really lock a mail server down, I always get 2 or 3 domains that are a nightmare of SMTP administration that require me to make exceptions. Like adding to white-lists (terrible practice), or water down the security by allowing improper rDNS values and mismatched banners.
I've had a decent sized bank look no different than a Nigerian scammer as far as their mail server was concerned. Unencrypted, failed SPF, no reverse DNS, banner mismatches, you name it. If I can't lock down because a mail client needs access to their bank, how can I draw a line in the sand and demand encrypted everything to my server?
We will see widespread encryption of the mail body before we see servers automatically encrypting emails between each other as a requirement.
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 2) by frojack on Monday November 02 2015, @09:26PM
Unencrypted, failed SPF, no reverse DNS, banner mismatches,
Its amazing how many places won't accept mail from Joe Random User. I end up forwarding all outbound through my hosting site, even though my MX points to my local Linux mail server for receipt. Even with a static IP and a certificate, some places will bounce your mail if your reverse even looks a little bit generic, and my current ISP will not let me control the reverse. The best they offer is a "BusinessClass" label in the reverse.
As for encryption, there is something to be said for webmail. Its usually all HTTPS, and its the easiest way to have Mom's mail set up.
I have opportunistic encryption set up on Thunderbird+Enigmail and it really isn't a problem to use. The Setup Wizard will pretty much do the whole thing these days, including setting up a key pair.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Tuesday November 03 2015, @11:22PM
> I don't even have the option to require all SMTP traffic to be encrypted, just that client connections be encrypted.
https://www.checktls.com/ [checktls.com]
This site will at least let you test if the last outbound hop before delivery is encrypted. I found out that my hosting provider was not doing that despite accepting encrypted incoming smtp connections.
(Score: 3, Insightful) by Runaway1956 on Monday November 02 2015, @01:56PM
"which should become commonplace shortly after Hurd achieves market dominance."
Huh?
(Score: 0) by Anonymous Coward on Monday November 02 2015, @02:42PM
I Hurd that on the grapevine.
(Score: 2) by Thexalon on Monday November 02 2015, @05:33PM
A geeky way of saying "When Hell freezes over", "When pigs fly", etc.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by DeathMonkey on Monday November 02 2015, @06:21PM
"which should become commonplace shortly after Hurd achieves market dominance."
Huh?
It's been a tough couple years since they finally release Duke Nukem Forever...
(Score: 0) by Anonymous Coward on Monday November 02 2015, @06:46PM
That is a reference to https://en.wikipedia.org/wiki/GNU_Hurd [wikipedia.org] and that is the GNU project's kernel. It began development before Linux and still isn't stable. Part of the problem is the difference between micro kernels and monolithic ones. But the other problems include the lack of man-hours by developers, the fragmented efforts (there are at least 3 kernels under the HURD banner that I can think of off hand, but most development is in GNU Mach) and the fact that systems are more complicated in order to get a "just works" result or higher security (see not only USB or WiFi but also PCIe and SSDs).
(Score: 1, Interesting) by Anonymous Coward on Monday November 02 2015, @02:05PM
Why would a sensitive email ever not be end-to-end encrypted anyway?
(Score: 2) by VLM on Monday November 02 2015, @02:14PM
with the NSA powning both endpoints of course. Aside from rubber pipe decryption technology.
(Score: 2) by SecurityGuy on Monday November 02 2015, @04:50PM
Because lots of people are involved in the decision of what's sensitive and what's not, and some get it wrong. I knew people in the healthcare sector who thought of nothing of forwarding all their email to hotmail. I can't imagine there aren't people in the financial sector who did the same when it was possible (and probably still do in places it isn't technically forbidden).
A decade or so ago I had briefly had a doctor who thought it was no big deal to tell me stories about other people's ills with enough detail that I could figure out who they were. People who should know better sometimes don't.
(Score: 5, Insightful) by ledow on Monday November 02 2015, @02:23PM
Given that email crosses any number of unknown servers, you should be wary anyway. Email is just not safe without entirely separate encryption even if part of the transit is secured.
You have no idea that the IT guy the other end isn't reading it, that the transit in-between doesn't involve forwards or bounces that you're not aware of, that the server itself is who it claims to be (TLS encryption is all well and good but anyone can be MITM and what "pins" a particular certificate to a particular mail-server? Do you need to have the certificate of the email domain to receive that email? No. Just people forwarding stuff direct to Google Mail tells you that's not necessary at all), that they aren't using a mail provider (e.g. mail.google.com as their MX), or even that simple DNS spoofing isn't occurring (how often do you check that your MX hasn't changed to some random third-party?).
Email has always been like this. Email is NOT secure. It can be read en-route by any number of points. If you want to send secure information, encrypt it separately and DON'T EMAIL THE KEY.
That this is inconvenient, e.g. needing things like PGP and webs of trust, is the main road-block to secure communication.
(Score: 0) by Anonymous Coward on Monday November 02 2015, @03:06PM
Email has always been like this. Email is NOT secure. It can be read en-route by any number of points. If you want to send secure information, encrypt it separately and DON'T EMAIL THE KEY.
That this is inconvenient, e.g. needing things like PGP and webs of trust, is the main road-block to secure communication.
Is there any effort to an "Email 2.0"? I don't know of any projects that aim to be replacement to current email protocols, but maybe they're just badly publicized?
(Score: 1, Informative) by Anonymous Coward on Monday November 02 2015, @03:31PM
The SSL/TLS settings in your mail client is for the username/password, not for the mail. Yes, it also encrypts the mail, for a few milliseconds before decrypting it again and forwarding it in plaintext.
If you want real e-mail encryption, use PGP or Gnu Privacy Guard. Outlook users may prefer X.500 certificates, but be aware than those are NSA-approved - and probably not readable by anyone else, but neither is RTF-emails anyway, so anyone who cares about communicating with non-Exchange-customers avoid Outlook like the plague.
(Score: 2) by VanderDecken on Monday November 02 2015, @03:54PM
Mostly right.
Yes, TLS is important to avoid exposing credentials in client-to-server communications. But part of the story is in server-to-server where no authentication is typically used. In that case, most servers will do opportunistic encryption, but that doesn't provide a lot of cover either as it can be easily MITM'd -- besides accepting things like self-signed certs, server-to-server will downgrade to cleartext if TLS isn't available (or claimed to not be available). One of the best things that can be said for server-to-server TLS for SMTP is it decreases the amount of cleartext traffic on the Internet (which is a good thing).
The biggest take-away from various comments (including the parent) is that if you want to have a reasonable amount of privacy use PGP/GPG or the equivalent.
The two most common elements in the universe are hydrogen and stupidity.
(Score: 2, Interesting) by eravnrekaree on Monday November 02 2015, @03:32PM
A big issue here is many email clients are simply garbage and that getting GPG to work is basically the domain of expert users, at least from my own experience, often involving installing obscure plugins to an email client, unintuitive design such as complex configuration settings and so on. The fact is if installing GPG in an email program involved more than one step users will not bother. I deal with common users all of the time and there is a general apathy regarding security and you tell them to install this plugin and that program and set a list of settings and it just flies right over their head and they keep on sending clear text emails. Many do not understand the security issues and why they should use encryption. The encryption should be enabled by default on all clients and work out of the box with no configuration. This is the only way to get your average user to start using it. Many email programs have no built in GPG when it should be a standard feature. Furthermore, it should work out of box with no configuration, however the user should be able to configure everything though the configuration settings if they want.
Another feature I would suggest is making configuration of the clients easier by a standard that would allow users to simply specify the email address (and password) to the client, using the domain part of the email address the client would use another protocol, probably DNS, to get the address and ports of the IMAP and SMTP servers. Again, for many common users entering IMAP and SMTP addresses overly complicates matters and many will not get this step right or will see this as just too much to deal with and will keep on using web mail. Again someone should be able to manually set their IMAP and SMTP server values if they want, and have many custom server profiles , but it shouldnt be required. Obviously its not a choice between making things easy for common users, and making things configurable and controllable for expert users, we can have both in the same software packages.
This is software design 101. Software should be able to work out of box with reasonable defaults, but someone should be able through configuration screens configure every aspect of the software if they want. Put lesser used expert settings deeper in the configuration dialogs, such as accessible by an expert settings tab or button.
(Score: 3, Interesting) by VanderDecken on Monday November 02 2015, @04:35PM
It is true that getting a working GPG implementation is too difficult for most users and MUA built-in support is mostly dismal. There is much traffic on various crypto mailing lists about how things could be improved to the point that "Johnny's grandma can do it". (Please avoid going off on a tangent re sexist or age-ist related rants, please.) The biggest problem seems to come down to key management, including how do you Grandma to understand assymetric keys, why they are important, how the halves differ, and how to manage them. And then there is the web-of-trust thing. Through many conversations I have yet to see a proposed solution that both protects the user and is understandable. (Most arguments seem to approach things either from the "hide details from most users" camp that makes it hard for someone to understand when there's a problem, or the "we just need a nicer UI with this New and Shiny Paradigm that uses an analogy that breaks down just when it matters" camp.
If anyone could come up with a decent solution, there'd be a lot of people interested in it. And I don't mean coding it, I'm talking about just being able to describe it all in detail, with extra points for non-functional mockups. I don't propose SN as the right medium for the conversation, though ...
See also Why Johnny Can't Encrypt [usenix.org]
Regarding not having to configure SMTP/IMAP options in clients: Meh. Given that there are no reasonable defaults for the username/password pair (and thus they need to be entered anyway), I don't think that having to enter the hostname is particularly onerous. Things like port numbers already have defaults and don't need to be entered. Should they default to using crypto? Probably. But overall, especially that it's a one-time thing, I don't see configuring your email client to be that much of a hassle. Probably the closest thing would be to define preferred SMTP and IMAP servers in the DHCP response payload, but in the world of mobile computing I would say that such information is going to be wrong more often than not, anyway. (About the only time it would be helpful is in enterprise deployments, and client configuration there is already a solved problem anyway.)
The two most common elements in the universe are hydrogen and stupidity.
(Score: 2) by frojack on Monday November 02 2015, @09:48PM
It is true that getting a working GPG implementation is too difficult for most users and MUA built-in support is mostly dismal.
Not really. Thunderbird+enigmail has a wizard that walks you through the whole process.
The hardest part is KNOWING about the need for it. Once you get beyond that its easy.
Tbird also knows about ports and servers for all large mail hosts. Give it an email address and it can sus out what the host, ports, and protocols are.
No, you are mistaken. I've always had this sig.
(Score: 2) by frojack on Monday November 02 2015, @09:52PM
Another feature I would suggest is making configuration of the clients easier by a standard that would allow users to simply specify the email address (and password) to the client, using the domain part of the email address the client would use another protocol, probably DNS, to get the address and ports of the IMAP and SMTP servers.
What horribly obsolete version of an email client are you using where you don't know this already exists? Try any recent thunderbird.
Just about everything you've asked for is availble in Tbird + the Enigmail add on. The Enigmail setup wizard does just about everything for you.
Of course, if you're still using Pine, you will have to work a little harder.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Monday November 02 2015, @03:46PM
What is the big deal anyway? This is as silly as someone who sends plaintext postcards being concerned that some postboxes could be transparent.
You should assume that any unencrypted email is travelling across the internet plaintext, potentially intercepted by anyone who is interested.
If your sensitive/secret email was not encrypted in the first place a broken STARTTLS is the least of your worries. Someone or something on any of the servers/connections your email passes through could read your email even if STARTTLS was working.
(Score: 2) by Hyperturtle on Monday November 02 2015, @04:32PM
yeah. this is like saying don't trust the notes you pass in class to not be encrypted unless you wrote it in a cryptic code yourself to ensure the content is encrypted and not readable by the systems/messengers/fellow students passing it on.
Or the mail system as you said.
Or notes on paper at the office that one photo copies and hands out for meetings or whatever.
I think the real concern here is SHOCK automatic safety automatically fails to unsafety so that it still works!
There's a reason it fails open... and that reason is probably tied to preventing a complete outage of the service if there are no redundancies in place that can encrypt it the same way.
A metaphor is any small medium business type of IT person that set up TCP based Syslog on a firewall probably has experienced first hand what happens when the server guys reboot the syslog server with no warning. Poof. No internets. And if in the middle of updates or if it is not a self-start on boot service, big problems result due to being too secure. (there are technical ways to never encounter this -- like, redundancy of the syslog server, the connections leading to it, etc--but all that duplication of effort costs money, so often.. UDP gets used instead, because syslog UDP doesn't even notice if the logger drops).