Independent security expert Per Thorsheim is the founder and main organiser of Passwordscon, a conference devoted to passwords.
In this article he calls for more mail servers to beef up their security – by adopting STARTTLS to prevent email eavesdropping.
People across the world have reacted to recent revelations of the NSA eavesdropping on internet communications.
In particular, revelations have shown eavesdropping based on tapping into cables directly, instead of accessing data through various internet providers.
In response we’ve now seen the Brazilian president talking about creating a national email service, and three German ISPs have launched an initiative to secure email within the country through encryption and using cables inside their own borders.
In January 1999 RFC 2487 was launched, named “SMTP Service Extension for Secure SMTP over TLS”. Easily explained: user-transparent opportunistic encryption of email between mail servers, as long as servers on both ends support it.
This RFC was obsoleted by RFC 3207 in February 2002, named “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Essentially the same thing, just updated. From now on referred to as STARTTLS support.
In the spring of 2010 a colleague of mine and myself conducted a survey of 345,000 domains and their mail servers, looking for STARTTLS support.
Our findings were depressing; 67% of all domains in Norway (.no) didn’t have any STARTTLS support configured for their mail servers. 17% had at least 1 mail server supporting it, while 16% had support for it on all domain associated mail servers.
Even when servers did support STARTTLS, they would often be equipped with badly configured, self-signed and expired SSL certificates. The mail server handling email for the Norwegian prime minister’s office identified itself using a demo certificate as Cisco Systems, Inc. in California!
Here’s a table I made showing SSL support for mail services with one of my providers in Norway. They offer a SSL protected web interface for my inbox, as well as SSL protection for the POP and IMAP protocols if I’m using a dedicated mail client.
So far so good, but that’s just protecting the communication between me and my provider. As soon as my mail leaves my provider, it goes unencrypted over the internet to its final destination server.
Anyone eavesdropping on lines or routers on the way can easily read my email, and nobody will know. I still haven’t been able to receive a reasonable answer to why they do not offer opportunistic SSL encryption on their public mail servers.
Google mail supports STARTTLS. Microsoft and their Hotmail service does not. Neither does Yahoo or Apple. Perhaps its time for a wakeup call?
In Norway we’re building support to convince the Norwegian government into establishing STARTTLS support on all government mail servers, so that chances of illegal eavesdropping of mail communications will be reduced. Today your email is probably sent just like a postcard in the real world, anyone who can intercept can read it.
Ivan Ristic and Qualys does a marvellous job with SSL Labs, identifying and helping to correct bad SSL implementations on web servers.
Through the Trustworthy internet Movement (TIM), the SSL Pulse survey provides statistics and shows progress over time.
I would really wish for Qualys to make SSL Labs check mail servers as well, and provide similar statistics. I have no doubt this would greatly improve our ability to increase information security and privacy for a communication channel that came to life long before the web, and that still carries vast amounts of secrets for all of us.
Several tools are available for checking mail servers for STARTTLS support, and mail headers will usually display information about it if opportunistic SSL encryption has been used during transmission between mail servers.
A simple web interface for checking mail servers for this kind of support can be found at checktls.com.
Re the "badly configured certificates" part – I disagree, they are configured as is allowed for opportunistic encryption.
The "opportunistic" in the spec means the certificates can be expired, have mismatched CN or altnames, not be signed by a trusted CA, and it should not matter. No mail server checks these parameters in the certificate when talking to a random MX server. It is opportunistic after all. All it is interested in is to get any kind of encryption running. So this is by design – a trade off made to make it dead simple, enabled by default, set and forget kind of thing.
There is an upcoming opt-in mechanism for indicating to sending mail server that it should also verify when sending to your domain, using DNSSEC DANE/TLSA, but thats just baaarely starting to get deployed.
Agreed. While it certainly makes for higher trust to have non-self signed and non-expired certs, it still has its uses: I use STARTTLS on my server and I have wildcard, self signed cert because why do I need to pay the money (I'm not a for profit company or a company at all even) just so I'm able to encrypt mail? Okay, sure, with NAT (which I hate any way) I have 'private' networks but that's besides the point and also not the only time it might be used (server to server communication?). The only time it is a possible problem is when it is for (example) e-commerce on a web site but let's be realistic: SSL and TLS have a long history of security problems (not even considering MITM attacks) and also, even if it's encrypted over the wire it does not necessarily mean it is encrypted on file (for companies that store credit card information, for example). Any way, as you point out (or I infer anyway), for smtp its less of an issue than say, https, to have expired certs (but even then I do the same for https; again, I have no customers so why would I pay money for it?). And lastly, most users are not going to know whether it is self signed or not (or what that means even) let alone know if their mail is encrypted at all. Maybe they should but they don't. I almost went over this the other day (responding to the BIOS malware post) but I didn't get to it before clicking submit comment. I'll just quote (sort of) the wonderful Ken Thompson and his article (Reflections on Trusting Trust): trusting trust is far too prevalent. Put another way, trust is given far too easily and that has wreaked havoc for many administrators over the years (rhosts.equiv anyone? That a single file could allow anyone to log in from any host without a password as long as they have the user name specified [and it is simple: create a user on either your own machine or as some would have done, a compromised machine] is quite scary but also an old and quite serious problem for many systems in the past) as well as users (there was also .rhosts file which an admin may be didn't even approve of and didn't block somehow, which then puts the entire system at risk as local access increases the ease of escalating your privileges).