A conversation i had the other day touched on the topic of transferring data via email and the risks this poses to the information contained. This kind of conversation seems to come up quite regularly and in many cases the assumption is made that mails sent via the internet are transferred in clear text unless both parties venture in the world of PKI and/or certificate exchange. While this was true not too long ago technological progress (for once you might argue) is in favour of messaging security with the availability of opportunistic encryption on mail gateways.

Now why does that matter? In short it means that a mail gateway which is correctly configured to use TLS encryption (STARTTLS) will attempt to deliver to other mail gateways and accept delivery from other gateways over an encrypted path. The good news is that many mail gateways provide this by default (e.g. Microsoft Exchange)

“In earlier versions of Exchange Server, you had to configure TLS manually. In addition, you had to install a valid certificate, suitable for TLS usage, on the server running Exchange Server. In Exchange 2007, Setup creates a self-signed certificate. By default, TLS is enabled. This enables any sending system to encrypt the inbound Simple Mail Transfer Protocol (SMTP) session to Microsoft Exchange. By default, Exchange 2007 also tries TLS for all remote connections.”

(http://technet.microsoft.com/en-us/library/bb430753%28EXCHG.80%29.aspx)

This is fairly easy to test by connecting to the mail gateway manually on TCP/25. In this case i’m using the main MX for google.com as a test subject.

[pro@localhost /]$ nc aspmx.l.google.com 25 

220 mx.google.com ESMTP l33si6440877weq.6
EHLO
250-mx.google.com at your service, [90.203.223.103]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 2.0.0 Ready to start TLS

Now we know that Google is capable of opportunistic encryption but to make this work both sides need to support this. As checking this via commandline is not particularly comfortable you can also use this convenient service http://www.ismymailsecure.com

 

Lastly there is the option to verify whether an email has been transferred via an encrypted communication by looking at the header information of the actual email. You should be able to see something similar to this

Received: from mail-yw0-f47.google.com ([209.85.213.47])
by bluemoon3.ukhost4u.com with esmtps (TLSv1:RC4-SHA:128)

This means that the email was encrypted while in transfer between the sending gateway and the receiving gateway. This is of course much better than sending information in clear text but obviously there are things to consider from a risk perspective. For one it does not ensure end to end encryption i.e. the email content might not be encrypted once it is handed from the mail gateway to the backend infrastructure. Further information on this, including some additional considerations around risk, can be found e.g. at the OpenSecurityArchitecture site. This diagram by the OSA shows the ‘SP-020: Email Transport Layer Security (TLS) Pattern‘