This post will focus on Email Transport Layer Security. This is often just called TLS and sometimes ‘starttls’. As the name implies, TLS protects the contents of traffic as it travels between endpoints on the internet by encrypting the content and by verifying the authenticity of the servers at the endpoints. The SSL/HTTPS used by browsers is a form of TLS that protects traffic flowing between browsers and web servers.
Email TLS protects the contents of emails as they travel between mail servers. For example if an educational service (let’s call it SuperDuperReaders.com) sends a class update to a teacher’s Google for Education email account, TLS can be used to encrypt the email as it travels from SuperDuperReaders.com’s email server to Google’s email server. (The Gmail interface will handle encryption between Google’s servers and the teachers email client). Google’s Safer Email site has more information about how this works, and I’ll refer to this site again later in the post.
This is back-end stuff and a remote threat compared to sending the same content from a mail server to a user’s email client without encryption — for example if the user is using an airport wifi to read the email and it’s not encrypted. However, maintaining a comprehensive security program means being mindful of potential risks to the security of information and systematically taking steps to protect against those risks. Another thing to consider is that sometimes a number of small vulnerabilities can be leveraged to create more powerful exploits. Furthermore I am not aware of a convincing reason for not supporting TLS for email/starttls. Security is difficult. It’s important to enable the “easy” protections when they are available.
One more detail of email TLS is that both ends of the connection must support it, and it is up to the server sending the mail to request that it be used for the transfer of information. (This is where ‘starttls’ comes from, it’s the name of the request for TLS from the server sending the mail). From the previous example, if SuperDuperReaders.com wanted to send email to a teacher’s Google Apps for Education email account using TLS, SuperDuperReaders would initiate the connection with Google and ask for TLS with a starttls request. Google’s server would reply that it’s supported by their server and the connection encryption would be set up.
Returning to Google’s Safer Email site: At this site Google posts daily percentages of mail sent and received using TLS for the domains with the most traffic to and from Google’s mail servers. For mail coming in to Google, the mail will only be sent with TLS if the other site (SuperDuperReaders for example) requests it. Google always requests TLS for email connections, so for mail leaving Google it will only be sent with TLS if the receiving domain supports TLS. The Safer Email website allows searches by domain name, and the data set can be downloaded from the site.
As an example, the screenshot below shows the results for edmodo.com from today’s dataset. Google reports that 0% of the mail entering Google from Edmodo is sent with TLS. This means that Edmodo’s servers are not requesting TLS when sending email. Outbound mail is not listed because not enough mail flows from Google to Edmodo to be recorded in this dataset.
(UPDATED: On March 11th Edmodo enabled STARTTLS for outgoing email, and this should show up in the Google Safer Email results by March 16th or 17th, as they lag by 5 days or so – thanks to Edmodo for quick response!)
I reported this to Edmodo in June, 2014 and at that time I generated a mail from Edmodo by entering a post in a test classroom, and examined the email headers to confirm that TLS was not used during transmission from Edmodo to my email account. The text of the email is shown below.
Though the message text is admittedly somewhat contrived, it does demonstrate a case where communications sent with an expectation of privacy, containing personal information of students, was sent across a portion of the network without encryption. (Not real students in this example.) Emails from other services might contain more sensitive information than what is in this example.
Google’s site is a way for end users to understand what companies are doing with email TLS without having to decipher email headers. It can also be used to check what school districts are doing if they send enough mail to be included in Google’s dataset. For example a data set downloaded today contained the domain names of some school districts and educational organizations that appear to be sending email without requesting TLS from the receiving side. These include.
browardschools.com, cherrycreekschools.org, fultonschools.org, charterschoolsusa.com
A search on domains with ‘k12’ that have 0% incoming TLS yields this:
beaumont.k12.tx.us, bluevalleyk12.org, cms.k12.nc. usmcms.k12.nc.us, cobbk12.org, dcsdk12.org, dpsk12.org, elkriver.k12.mn.us, forsyth.k12.ga.us, greenville.k12.sc.us, henrico.k12.va.us, jeffco.k12.co.us, mason.k12.oh.us, sdhc.k12.fl.us, sheboygan.k12.wi.us, worthington.k12.oh.us
Note that Google’s Safer Email data set changes day to day based on the amount of email traffic seen by google per-domain.
For those inclined, here is how to check if email in a gmail inbox was sent to Gmail with TLS:
Select the “show original” menu item for the mail you want to check.
This will bring up a view of the email header. Look for “TLS” in the text.
For example the here is part of the headers for the mail above, confirming it was sent from Yahoo to Google using TLS.
For completeness, here is the similar portion of headers for the mail from Edmodo in June (shown earlier in the post), sent without TLS from Edmodo to Google.
(updated after posting to add k12 domains to the list of school district domains with 0% TLS)