How Can You Tell if an Email Was Transmitted Using TLS Encryption?

Frequently, we are asked to verify if a sent or received email was encrypted using SMTP TLS during transmission. For example, banks, healthcare organizations under HIPAA, and other security-aware institutions require that emails be secured by TLS encryption.

Email should always be transmitted with this basic level of email encryption to ensure that the email message content cannot be eavesdropped upon. To see if a message was sent securely, looking at the raw headers of the email message in question is easy. However, it requires some knowledge and experience to understand the text. It is actually easier to tell if a recipient’s server supports TLS than to tell if a particular message was securely transmitted.

To analyze a message for transmission security, we will look at an example email message sent from Hotmail to LuxSci. We will see that Hotmail did not use TLS when sending this message. Hotmail is not a good provider to use when security or privacy are required.

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 their email server.

(for more details, see this article)

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 intermediate step, where the email is transmitted between two different providers,  is where messages may be insecurely transmitted.

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, the lines at the top start with “Received.” In an example email message from someone on Hotmail, the Received headers look like this. The email addresses, IPs, and other information are fake for obvious reasons.

LuxSci:

Received: from abc.luxsci.com ([1.1.1.1])
	by def.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfLgH003867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2019 10:41:21 -0400
Received: from abc.luxsci.com (localhost.localdomain [127.0.0.1])
	by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfK0Z030182
	for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2019 09:41:20 -0500
Received: (from mail@localhost)
	by abc.luxsci.com (8.14.4/8.13.8/Submit) id r7JEfKXD030178
	for user-xyz@def.luxsci.com; Mon, 19 Aug 2019 09:41:20 -0500

Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [2.2.2.2])
	by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfIkK030002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <someone@luxsci.net>; Mon, 19 Aug 2019 09:41:19 -0500

Proofpoint:

Received: from unknown [65.54.190.216] (EHLO bay0-omc4-s14.bay0.hotmail.com)
	by dispatch1-us1.ppe-hosted.com.ppe-hosted.com
        (envelope-from <someone@hotmail.com>);
	Mon, 19 Aug 2019 08:41:18 -0600 (MDT)

Hotmail:

Received: from BAY403-EAS373 ([65.54.190.199]) by bay0-omc4-s14.bay0.hotmail.com
       with Microsoft SMTPSVC(6.0.3790.4675); 
       Mon, 19 Aug 2019 07:41:19 -0700

What do These Received Headers Say?

The things to notice about these Received headers are:

1. 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.
2. Each Received line documents what a server did and when.
3. There are three sets of servers involved in this example: one machine at Hotmail, one machine at Proofpoint, where our Premium Email Filtering takes place, and some machines at LuxSci, where final acceptance of the message and subsequent delivery happened.

Presumably, the processing of email within each provider is secure. So, you have to watch out for the hand-offs between Hotmail and Proofpoint and between Proofpoint and LuxSci, as these are the big hops across the internet between providers.

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

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

This section, typical of most email servers running “sendmail” with 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 Proofpoint for a second SSL client certificate to verify itself, as that is not usually needed or required for SMTP TLS to work correctly). Also, “TLSv1/SSLv3” is a tag that means that “Some version of SSL or TLS was used;” it does not mean that it was SSL v3 or TLS v1.0. It could just as well have been TLS v1.2 or TLS v1.3.

So, the hop between Proofpoint and LuxSci was locked down and secure. What about the hop between Hotmail and Proofpoint? The Proofpoint 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, at this time, either Hotmail did not support opportunistic TLS encryption for outbound email, OR Proofpoint did not support receipt of messages over TLS, and thus TLS could not be used. Without further context, you would not know which server (or both) did not support TLS.

We know that Proofpoint, like LuxSci, supports inbound TLS encryption. In fact, from another example message where LuxSci sent a message to Proofpoint, we see the Received line:

Received: from unknown [44.44.44.44] (EHLO wgh.luxsci.com)
	by dispatch1-us1.ppe-hosted.com.ppe-hosted.com
        (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	with ESMTP id b-022.p01c11m003.ppe-hosted.com
        (envelope-from <from@domain.com>);
	Mon, 02 Feb 2009 19:28:27 -0700 (MST)

The red text makes it clear that the message was indeed encrypted.

Some things to consider when analyzing email headers for encryption usage

1. The receiving server will log what kind of encryption, if any, was used in receiving the message in the headers.
2. Different email servers use different formats and syntax to display what kind of encryption was used. Look for keywords like “SSL,” “TLS,” “Encryption,” etc., which will signify this information.
3. Not all servers will record the use of encryption; nothing says that they have to encrypt email. While LuxSci has always logged encryption use, McAfee has only been logging this since 2008. Before that time, TLS encryption was still possible and normal with their servers, but there was no way to tell from the headers if it was used.
4. 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 many servers so that information can pass between them without SMTP TLS, but where the data is still secured. So, the lack of TLS usage between two servers does not mean that the transmission between them was “insecure.” You may also see multiple received lines listing the same server: the server passes the message between different processes within itself. This communication also does not need to be TLS encrypted.
5. If you are a LuxSci customer, view the online email delivery reports to see if TLS was used for any particular message. We record the kind of encryption in thr delivery reports, so there is no need to read message headers.

How can you ensure Secure Message Transmission?

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

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

1. Proofpoint and LuxSci will always log the use of TLS in the headers. This tells us that the Hotmail to Proofpoint hop was not secure as nothing is recorded there.
2. The transmission of messages within LuxSci’s infrastructure is secure due to private back channel transmissions. So, even though there is no mention of TLS in every Received line after LuxSci accepts the message from Proofpoint (in this example), the transfer of the messages between servers in LuxSci is as secure as using TLS. Also, multiple received lines can be added by the same server as it talks to itself. Generally, these hand-offs on the same server will not use TLS, as there is no need. We see this also in the LuxSci example, as “abc.luxsci.com” adds several headers.
3. We don’t know anything about Hotmail’s email servers, so we don’t know how secure the initial transmissions within their network are. However, since we know that they did not securely transmit the message to Proofpoint, even though they could have, we do not have much confidence that the transmissions and processing within Hotmail (which may have gone unrecorded) were secure at all.

Read more:  Can you really be sure if an email message was transmitted using TLS?

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 ensure 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 (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 (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 ensure it is secure; you can’t control the other without taking extra steps. 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 access 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 set up anything 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 essential recipients will always be transmitted securely, that is the best solution.