Frequently, we are asked to verify if an email that someone sent or received was encrypted using SMTP TLS while being transmitted over the Internet.  For example, banks, health care organizations under HIPAA, and other security-aware institutions have a requirement that email be secured at least by TLS encryption from sender to recipient.  This can and should be locked down to ensure that the email message content cannot be eavesdropped upon.  This check, to see if a message was sent securely, is fairly easy to do by looking the the raw headers of the email message in question.  However, it requires some knowledge and experience.  It is actually easier to tell if a recipient’s server supports TLS than to tell if a particular message was securely transmitted.

To see how to analyze a message for its transmission security, we will look at an example email message sent from Gmail to LuxSci, and see that Gmail does not use TLS when sending messages, even when it can.  This indicates that Gmail is probably not a service to be used when you have any kind of encryption requirements.

An Example Email Message

First, we must understand that an email message typically passes through several machines on its way from sender to recipient.  Roughly speaking:

1. The sender’s computer talks to the sender’s email or WebMail server to upload the message.
2. The sender’s email or WebMail server then talks to the recipient’s inbound email server and transmits the message to them.
3. Finally, the recipient downloads the message from his/her email server.

It is step 2 that people are most concerned about; they usually assume or check that everything is secure and OK at the two ends.  Indeed, most users who need to can take steps to ensure that they are using SSL-enabled WebMail or POP/IMAP/SMTP/Exchange services so that steps 1 and 3 are indeed secure.  The middle step, where the email is transmitted between two different providers,  is where most messages are insecurely transmitted.

In order to determine if the message was transmitted between the sender’s and recipient’s servers securely (over TLS), we need to extract the “Received” header lines from the received email message.  If you look at the “source” of the email message, these are all the lines at the top that start with “Received:”.  In an example email message that I received today from someone on Gmail, the Received headers look like this (I replaced the email addresses, IPs and such with fake ones for obvious reasons):

At LuxSci:
Received: from abc.luxsci.com ([10.10.10.10])
	by 123.luxsci.com (8.13.7/8.13.7) with
       ESMTP id n0UM2HJM010309
	for <user-456@123.luxsci.com>;
       Fri, 30 Jan 2009 16:02:17 -0600
Received: from abc.luxsci.com (localhost
       [127.0.0.1])
	by abc.luxsci.com (8.13.7/8.13.7)
       with ESMTP id n0UM2Hek005822
	for <user-456@123.luxsci.com>;
       Fri, 30 Jan 2009 16:02:17 -0600
Received: (from mail@localhost)
	by abc.luxsci.com (8.13.7/8.13.7/Submit)
       id n0UM2HSI005813
	for user-456@123.luxsci.com;
       Fri, 30 Jan 2009 16:02:17 -0600
Received: from p01c11m095.mxlogic.net
       (mxl144v247.mxlogic.net [208.65.144.247])
	by abc.luxsci.com (8.13.1/8.13.7)
       with ESMTP id n0UM2Hq2005783
	(version=TLSv1/SSLv3
       cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <sender@domain.com>;
       Fri, 30 Jan 2009 16:02:17 -0600

At MX Logic:
Received: from unknown [74.125.92.149]
       (EHLO qw-out-1920.google.com)
	by p01c11m095.mxlogic.net (mxl_mta-6.1.0-2)
	with ESMTP id 8086.p01c11m095.mxlogic.net
       (envelope-from <sender@gmail.com>);
	Fri, 30 Jan 2009 15:02:16 -0700 (MST)

At Google:
Received: by qw-out-1920.google.com with
        SMTP id 5so170135qwc.8
        for <recipient@domain.com>;
        Fri, 30 Jan 2009 14:02:16 -0800 (PST)
Received: by 10.214.81.5 with SMTP id
       e5mr3026338qab.305.1233352936308;
       Fri, 30 Jan 2009 14:02:16 -0800 (PST)

What do These Received Headers Say?

The things to notice about these Received headers are:

• They are in reverse chronological order.  The first one listed shows the last server that touched the message; the last one is the first server that touched it.
• Each Received line documents what a server did and when.
• There are three sets of servers involved in this example: two machines at Google, one machine at MX Logic, where our Premium Email Filtering takes place, and some machines at LuxSci where final delivery happened.

Presumably, the processing of email within each provider is secure (though maybe that is too presumptuous for many providers — it is true of LuxSci).  So, what you really have to watch out for are the hand-offs between Google and MX Logic and between MX Logic and LuxSci … as these are the big hops across the Internet between providers.

In the line where LuxSci accepts the message from MXLogic, we see:

(version=TLSv1/SSLv3
cipher=DHE-RSA-AES256-SHA
bits=256 verify=NOT)

This section, which is typical of most email servers running “sendmail” that have TLS support, indicates that the message was encrypted during transport with TLS using 256-bit AES encryption. (“Verify=not” means that LuxSci did not ask MX Logic for a second SSL client certificate to verify itself, as that is not usually needed or required for TLS to work properly) .

So, the hop between MX Logic and LuxSci was locked down and secure.  What about the hop between Google and MX Logic?  The MX Logic server’s Received line makes no note of security at all!  This means that the message was probably NOT encrypted during this step.  Whose fault is that?  Well, either Google doesn’t support TLS encryption when the recipient does, or MX Logic doesn’t support TLS encryption of inbound email messages (or just doesn’t record it).

We know for a fact that MX Logic, like LuxSci, supports inbound TLS encryption.  In fact, from another example message that we have, where LuxSci itself was sending a message to MX Logic, we see the Received line:

Received: from unknown [44.44.44.44] (EHLO wgh.luxsci.com)
	by p01c11m003.mxlogic.net (mxl_mta-6.1.0-3)
        over TLS secured channel
	with ESMTP id b-022.p01c11m003.mxlogic.net
        (envelope-from <from@domain.com>);
	Mon, 02 Feb 2009 19:28:27 -0700 (MST)

It is apparent that the message was indeed encrypted.  However, unlike LuxSci, MX Logic does not record what kind of encryption was used, just that it was “over a TLS secured channel”.

Some things to consider when making your own analysis of email headers for encryption usage

• It is the receiving server that will log what kind of encryption, if any, was used in the receipt of the message.
• Different email servers use different formats and syntax to display what kind, if any, encryption was used in the receipt of the message.  You should look for keywords like “SSL”, “TLS”, “Encryption”, etc., which will signify this information.
• Not all servers will record the use of encryption — there is nothing that says that they have to encrypt email.  I.e., while LuxSci has always logged encryption use,  MX Logic has only been logging this for the last year or so.  Prior to that time, encryption was still possible and normal with their servers, but there was no way to tell from the headers if it was in fact used.
• Messages passed between servers at the same provider do not necessarily need TLS encryption to be secure.  For example, LuxSci has back-channel private network connections between its servers so that information can pass between them unencrypted but not subject to eavesdropping by any other server anywhere.  This is faster and more efficient than using TLS on every connection.  So, the lack of TLS usage between two servers does not mean that the transmission between them was “insecure” per-se.

With some servers not reporting use of TLS, and in some cases TLS not being needed, how can you really determine if a message was transmitted securely from sender to recipient?

You really have to understand the properties, servers and networks involved in order to answer this question accurately.  While you may be able to answer in the affirmative, based on headers, in some cases, you cannot necessarily answer in the negative without knowing what things are recorded by each system’s servers. In our example of a message from Gmail to LuxSci, you need to know that:

• MX Logic and LuxSci will always log use of TLS in the headers — this tells us that the Google to MX Logic hop was not secure as nothing is recorded there.
• Transmission of messages within LuxSci’s infrastructure is secure due to private back channel transmissions.  So, even though there is no mention of TLS after LuxSci accepts the message from MX Logic, the transfer of the messages between servers in LuxSci is effectively as secure as using TLS.
• We don’t know anything about Google’s email servers and so don’t know how secure the initial transmissions within their network are.  However, since we do know that they did not transmit the message to MX Logic securely, even though they could have, we do not have much confidence that the transmissions within Google were secure at all.

What about the initial sending and receipt of the message?

So, we skipped steps 1 and 3 and focused on step 2 — the transmission between servers.  Steps 1 and 3 are equally if not more important.  Why?  Because eavesdropping on the Internet between ISPs is less of a problem than eavesdropping near the sender and recipient (i.e. in their workplace or local wireless hotspot).  So, one must take care that messages are sent securely and received securely.  This means:

• Sending: Use SMTP over SSL or TLS when sending from an email client or use WebMail over a secure connection (SSL / HTTPS).
• Receiving: Be sure that your POP or IMAP connection is secured via SSL or TLS; If using WebMail to read your email, be sure it is over a secure connection (SSL / HTTPS).
• WebMail: There is generally no record in the email headers to indicate if a message sent using WebMail was transmitted from the end user to WebMail over a secure connection (SSL  / HTTPS).

You can generally control one side and make sure that it is secure; you generally can’t control the other.  So, what can you do to ensure that your message is secure even if it might not be transmitted securely and if your recipient might try to download it insecurely?  You could use end-to-end email encryption (like PGP or S/MIME which are included in SecureLine) or a secure email pickup service like SecureLine Escrow that doesn’t require the recipient to have to install or setup anything in order to get your secure email message.  These all meet the security requirements of HIPAA, and organizations that mandate email transmission encryption.

Of course, if you can ensure that the email sent from you to your important recipients will always be transmitted securely, that is the best solution.

Similar Posts:

• Tracing the Origin of an Email Message — and Hiding it
• SMTP TLS: All About Secure Email Delivery over TLS
• How to Tell Who Supports TLS for Email Transmission
• Gmail – Not HIPAA Compliant Email
• Enforcing and Detecting TLS Email Encryption on Inbound Messages