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.
If you have an article that you’d like to share on grahamcluley.com, please do get in touch.
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.
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.